Mozilla Languages Enabling Projects - Schedule

Table of Content:

• Schedule for Mozilla Languages Enabling Projects
• Mozilla I18N feature In / Out List for Netscape 5.0 Branch- DRAFT, FINALIZED
• Brendan Eich's message about schedule (for Mozilla tree in general)
• Frank Tang's message about schedule (for Mozilla i18n work)

June 1, 1998- Passed

Mozilla tree Stabilization freeze 1: after Mail/News merge- (several days ???)

June 15, 1998- Passed

Last date to tell ftang that you want to own I18N feature. I18N feature have no owner will be drop. Take a look at the "DRAFT Mozilla I18N feature In / Out List for Netscape 5.0 Branch" and sign up the one you want to own. ftang will publish a "FINALIZED Mozilla I18N feature In / Out List for Netscape 5.0 Branch" in June 16, 1998.

July 1, 1998-

Mozilla tree Peformance tuning freeze : Working on tuning performance (several days ???)

Auguest 1, 1998-

Mozilla tree Stabilization freeze 2: (several days ???)

Auguest 10, 1998-

Last date to send I18N feature patch to ftang for 5.0 so ftang have 20 days to merge and check in your patch into Mozilla source.

September 1, 1998-

Close the trunk to new features and stabilize aggressively, to get the inter-module bugs and hard heisenbugs fixed. After this day, you could still submit patch for bug fixing. I18N feature like enable a new writing system/encoding have to be done in branch and will not go into Netscape 5.0 tree.

• The default In / Out status is default to Out unless we have feature owner.
• Send mail to ftang by June 15, 1998 if you want to change this list. But you have to tell me that you want to own the feature and could give me the implementation in patch form by Auguest 10, 1998.

• Armenian Enabling
  • Feature Owner: Hovik Melikyan <hovik@undp.am>
  • Status: XP/WinFE/XFE - Done, MacFE - Not Done
• Arabic and Hebrew (Bi-Di) Enabling
  • Feature Owner: Franck Portaneri <franck@langbox.com> and alex khalil <iskandar@ee.tamu.edu>
    
  • Status: Need Mac, Window develpers. A lot of XP work
• Baltic Enabling
  • Feature Owner: Ricardas Cepas <rch@ip.lt>
    
  • Status: Unclear
• Chinese Conversion- Big5 to/from EUC-TW
  • Feature Owner: Leong Kok Yong <kokyong@irdu.nus.edu.sg>
  • Status: ftang check in new Big5 to/from EUC-TW conveters
• Chinese Enhancement- ISO-2022-CN
  • Feature Owner: Leong Kok Yong <kokyong@irdu.nus.edu.sg>
  • Status: Unclear
• Chinese Enhancement- GBK (GB13000)
  • Feature Owner: Chen Xiangyang <chenxy@sun.ihep.ac.cn>
  • Status: Unclear
• Georgian Enabling
  • Feature Owner: Nino Doijashvili <nino@homecom.com>
    
  • Status: Unclear
• Indic Scripts Enabling
  • Feature Owner: Anupam Saurabh <anupam@cdac.ernet.in>
    
  • Status: Unclear
• Thai Enabling
  • Feature Owner: Samphan Raruenrom < samphan@email.ksc.net>
  • Status: Pre-ALPHA stage LibInThai have been make public. Need to port to UNIX and Mac
• Ukrainian Enabling
  • Feature Owner: Dmitry Kohmanyuk <dk@farm.org>
    
  • Status: Unclear
• UNIX Non-Latin1 Printing Enhancement
  • Feature Owner: CHOI Junho <junker@jazz.snu.ac.kr>
  • Status: Liu Hai's 4.x patch have been merged into mozilla source base and the for-review-purpose-only patch have been post.
• Vietnamese Enabling
  • Feature Owner: Tin V Le <tin@szebra.saigon.com>
  • Status: unclear

OUT List for 8/10 Dead line: (No Feature Owner)

• Chinese Enhancement- Add CNS plan 3-7 in EUC-TW
• Chinese Enhancement- HZ
• Chinese Enhancement - Big5+
• CJK Enhancment: Kinsokut.c Kinsokud.c performance tuning
• CJK Enhancement - Ruby
• CJK Enhancement - Vertical Writing
• CJK Enhancement - Platform Independent Input Method support
• Customized Encoding Menu
• I18N Enhancment: Map lied font charset to correct charset on X
• I18N Enhancment: Map lied font charset to correct charset on Window
• I18N Enhancment: Map lied font charset to correct charset on Macintosh
• I18N Enhancment: Multiple charset in one HTML
• Korean Enhancement: Full range Unicode 2.0 Hangul support by using Johab font
• UNIX HTML Form TEXT and TEXTAREA locale independent enhancment for single byte charset

Brendan Eich's message about schedule (for Mozilla tree in general) - news://news.mozilla.org/355CEA2B.7288@netscape.com

Here are my current thoughts on mozilla scheduling for this year:

1.  May-June: Get mail and news integrated, fix more bugs, finish and
integrate features, strive for "24 by 7, I live in my mozilla build"
stability.

2.  July-August: Coordinated development and integration of more
ambitious features (feature list to be figured out later, but we already
have good leads thanks to everyone posting to these newsgroups).

3.  1-Sept-1998: Close the trunk to new features and stabilize
aggressively, to get the inter-module bugs and hard heisenbugs fixed.

4.  XXX-1998 (let's say it's 1-Oct-1998): Declare the trunk stable, tag
it with a blessed CVS label that anyone can use to derive product from
(particularly, but certainly not exclusively, Netscape for Communicator
5.0), and then:

5.  XXX plus 1: open the tree to next-gen layout, aggressive modularity,
other changes.  I should emphasize that the difference between 1-Sept
and this date cannot be many months, or we're doomed.

Right now, the code has a not-well-enough-known set of bugs that we
believe make it of "alpha" or at best "beta" quality.  But we don't know
for sure, because (we think) without mail/news and SSL, it's hard for
anyone to live 24-by-7 in mozilla.  And therefore the bug discovery rate
(as measured by bugs reported to http://www.mozilla.org/bugs) is too
low.

I know some folks prefer their own mailers and are using their mozilla
build as their browser, but the lack of SSL hurts.  Sure, you can get
patches from the SSLeay folks, but not everyone does that (and perhaps
the patches don't work against the current source?).

Until we have working solutions for mail/news and SSL, I don't see how
to get the 24x7 aggressive stabilization effect of everyone living in
their mozilla builds.  Am I unduly pessimistic?

If I'm not, then the dated steps 1-5 above are the best-case coarse
schedule for getting to a stable CVS tag from which various "5.0" era
browser-based products can be derived that I can come up with.

All comments and suggestions are welcome.

For the moment, barring a better idea, let's keep 1-Sept-1998 in mind as
the date when features stop going in and aggressive stabilization
begins.  It's very likely there will be earlier stabilization periods
leading up to September 1st, and I'll post a more detailed schedule as
soon as it's known.

/be

Frank Tang's message about schedule (for Mozilla i18n work) - news://news.mozilla.org/3560BDCE.1E6BC6A5@netscape.com

Now, here is my plan. It is very rough and is changable if you can tell me a good reason.

• Armenaian Enabling: We need someone to work on MacFE.
• XP- Done.
• WinFE-Done,
• XFE-Done.
• MacFE- NOT YET.
• Georgian Enabling: Should be easy to do, but I see no owner yet. I will be forced to drop this if no one tell me s/he is working on this by June 20.
• XP- NOT DONE.
• WinFE- NOT DONE,
• XFE- NOT DONE,
• MacFE- NOT DONE
• Baltic Enabling: Should be easy to do, but I see no owner yet. I will be forced to drop this if no one tell me s/he is working on this by June 20.
• XP- NOT DONE.
• WinFE- NOT DONE,
• XFE- NOT DONE,
• MacFE- NOT DONE
• Thai Enabling: I think we are close to have this. But, unless I see there are people working on one more platform and have public line breaking code in good quality by June 20, I wil bel forced to drop this.
• XP- NOT DONE, Need public line breaker and laytext.c changes.
• WinFE- NEED MERGE
• XFE- NOT DONE.
• MacFE- NOT DONE
• Indic Language Enabling: I think we are far from having it. Unless, by June 20, someone could tell me s/he will solve all the XP/FE issue on at least two platforms ( out of XFE, MacFE, and WinFE), I wil bel forced to drop this.
• XP- NOT DONE
• WinFE- NOT DONE
• XFE- NOT DONE.
• MacFE- NOT DONE
• Arabic Language Enabling: I think we are far from having it. Unless, by June 20, someone could tell me s/he will solve all the XP/FE issue on at least two platforms ( out of XFE, MacFE, and WinFE), I will be forced to drop this.
• XP- NOT DONE
• WinFE- NOT DONE
• XFE- NOT DONE.
• MacFE- NOT DONE
• Hebrew Language Enalbing:  I think we are far from having it. Unless, by June 20, someone could tell me s/he will solve all the XP/FE issue on at least two platforms ( out of XFE, MacFE, and WinFE) by 8/10 , I will be forced to drop this.
• XP- NOT DONE
• WinFE- NOT DONE
• XFE- NOT DONE.
• MacFE- NOT DONE
• UNIX Printing Enhancment:
• Unless someone are willing to own it and tell me his/her plan for it by June 20, I wil bel forced to drop this.

So, in summary:

1. If you really want to see it in 5.0 and you can work on it (don't tell me you wish, only tell me if you can work on that.), tell me by June 20 (to this newsgroup) or I will drop it.
2. In June 25, I will post a list what will be in and what will be out for 5.0
3. Give me your work by 8/10 so I have time to merge it.
4. Mozilla tree will be closed on 9/1
5. You can continute working on something drop from the list and we can maintain the patches somewhere public, but you have to understand those change won't put into mozilla tree untill the tree is open for FEATURE.
6. Bug fixes could go in after 9/1.

Please do not send message to me said "XXX Language is important  so you have to have it on 5.0". I agree with you, but we also need to deal with the reality that we need people to working on code and we need sleep. If you feel strongly we need to support XXX Language, then spend your time work on that or help us to find more people work on that. Send me message said "XXX Language is important, so you have to have it on 5.0, so I hack it in the past 5 days, and here are the patch" instead.

I know all of you working very hard on the Mozilla source. I do appreciate your help and feedback. Let's focus on what we can do for 5.0 now :)

Frank Tang