Doug,

  I would prefer option #1.  Probably more people will test it
earlier, and if they don't like it so much, we can back it out and
pretend nothing had happened before the major version up^^;

  Having different encodings for sources and changes doesn't matter
too much even for the program that read and write .sources and
.changes.  Such programs don't write into .sources and wouldn't have
made any assumptions of the relation ship between the chunk size in
file and in memory, because it has been different due to the text
attributes.

  Yes, Japanese font can be in different package and we can put font
unload mechanism to shrink the image.

  As I wrote, I'd try to work on this around the new year time.

-- Yoshiki

At Mon, 8 Dec 2003 00:52:06 -0500,
Doug Way wrote:
> 
> 
> On Sunday, December 7, 2003, at 03:40 PM, Yoshiki Ohshima wrote:
> 
> >   Since it handles different encodings for different files, the
> > .sources file *doesn't* have to be changed.  Of course, it is
> > preferable to change it.  The encoding of .changes will have to be
> > changed.
> 
> It looks like we have a few options:
> 
> 1. Include m17n (multilingualization) very soon in the 3.7alpha update 
> stream. (after m17n is brought up to date again)  This means that the 
> encoding for the .changes file will be different than the .sources file 
> for the 3.7 release, which would be odd, but might not be terrible.  
> The .sources file encoding would be updated whenever we moved to 4.0, 
> which might be the release after 3.7.  Also, m17n is a large, 
> time-consuming update, but I guess we probably wouldn't include the 
> actual japanese fonts, which make up the bulk of the size.
> 
> 2. Wait until after 3.7 is released in a few months, and then include 
> m17n as the first thing in 4.0alpha.  In 4.0 the .sources file would be 
> re-created in the new encoding.  (Might as well use the new condensed 
> sources stuff too.)
> 
> 3. Same as #2, except we release 3.7 very soon, so that 4.0alpha is 
> also opened soon and m17n is added early in 4.0alpha.
> 
> There might be other options.
> 
> Actually, I don't like option #3 that much, but either #1 or #2 or 
> something similar sounds okay with me.  I think it might be good to 
> have a little bit of time before we open 4.0, so we can figure out what 
> other big changes we might want to include in the major version number 
> upgrade.  (Changes requiring an image-format change, etc.)
> 
> - Doug
> 
> 
> >   Certain programs, that compares a Character with another by #==,
> > assuming the defualt file stream is StandardFileStream, and etc. will
> > stop working.  But it should be easy to fix those packages.
> >
> > -- Yoshiki
> >
> > At Sun, 7 Dec 2003 14:35:51 +0100,
> > ducasse wrote:
> >>
> >> Hi marcus
> >>
> >> I do not know. When yoshiki wants. I'm sure that I really understand
> >> the impact of the changes.
> >> Will the source of the methods get impacted? Does it mean that we will
> >> have to have a new source file?
> >>
> >> Stef
> >>
> >> On Dimanche, déc 7, 2003, at 13:12 Europe/Zurich, Marcus Denker wrote:
> >>
> >>>
> >>> Am 06.12.2003 um 09:21 schrieb Yoshiki Ohshima:
> >>>
> >>>>
> >>>>   In short, I need to tweak my package one more time anyway.
> >>>>
> >>>>   What I would like Doug and Guides to do is to freeze the update 
> >>>> for
> >>>> a moment so that I can make a compatible version with the latest
> >>>> alpha.  Otherwise, every little conflict beats me and it would never
> >>>> get merged.
> >>>>
> >>>
> >>> Yes. We should freeze the update stream for getting m17n in.
> >>>
> >>> It's really important to get this merged back. When do you think we
> >>> should do the freeze?
> >>>
> >>>    Marcus
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Marcus Denker marcus at ira.uka.de
> >>>
> >>>
> >>
> >>
> 
>