|
We are closing in on M3 milestone which contains about 70-80% of the features
needed
for our dogfood target.
Here are the following objectives we want to accomplish in the upcoming M3
milestone.
- Confirm the list of features that are working by giving them a good shakeout,
and writing a list of bugs that detail problems associated with each of the
features.
- Continue to identify and track performance problems, layout/rendering/and
drawing problems. We may not take the time or effort at this point to fix all or even most of
these problems, but its a good first step to get them logged in the database and a general milestone
assignment made. We want to keep the window for fixing any low hanging fruit problems to around
2-3 days early next week. The rest of the bugs will be moved off to m4,5, and 6.
- We want to create a stable, well known entry point to additional attract
developers. The existence of the entry point will we highlighted on mozilla.org as the
tarball/binaries developers and volunteer tester can download to start getting familiar with
seamonkey, without having to track the bleeding edge of the daily tip.
We want to establish a good check point where we make sure we can get clean
builds on the maximum number platforms possible at this time, and we want to get a
good listing of the system setups and dependencies needed to produce a build and run
it. We will be looking for patches and configuration information from all the ports
contributors to help get this information doc'ed. Ports contributors can pull a tree Monday
morning to synch with the efforts to make M3 milestone builds.
- We also want to start getting in the mode of doing these milestone releases
about every 3 weeks, and refining our processes for these milestones. Understanding the length of time it takes to do a good shakedown of the builds,
finding problems that slowdown or block testing, and getting this information collected and distributed is also important.
Here is the game plan for the M3 Milestone:
The tree closes Sunday at Midnight 3/14/99 for the M3 milestone.
Step 1 is to get a set of builds from Wed., Thursday and Friday morning to
start an exhaustive evaluation and testing period. Testers and Engineers should start to
pre-load bugzilla with milestone stopper bugs by assigning them as M3. An M3 stopper is a bug that
hinders building, development, evaluation, testing, or general use or the objective
listed above.
Friday at 11:00a and 4:00p we will start the M3 bug triage meetings in the
bld 21 pit at Netscape to get a handle on, and make sure we are focused on looking at
and fixing the most critical bugs and areas for improvement.
Some development work will go on in parallel up until Friday 3/12, but we
should start to taper or not introduce major changes between Friday and Sunday Midnight.
Starting Monday morning the tree will close for a day or more depending on
how stable the Monday Morning builds look after initial testing. During this time the
following things happen:
Continue with intense testing and evaluation of the builds on Monday.
Evaluation includes engineers running profilers, purify, and debuggers on any
crashes that are found, QA rendering comparisons, speed comparisons, and crash bug
finding on top sites. Monday at 4:00p there is a meeting to review M3 status, and approve
candidate M3 bug fixes for checkin. If the Monday morning builds are in bad shape, M3 work stays on
the trunk and we will only allowing checkins that fix the most critical M3
stopping bugs.
If we look stable and don't have a large number of bugs to triage and fix we will create an M3 branch Tuesday morning and open the trunk.
Tuesday and Wed. work on building a list of known problems, synchronizing
and updating mozilla build docs, and doc'ing the milestone release continues and wraps
up. Thursday morning the M3 source tarballs and binaries get prominently
published on mozilla.org. Thursday we will also check to make sure any changes introduced on the M3
branch are folded back into the trunk.
Here's Akkana's update on the status of the editor (composer):
"We've been focusing on fixing bugs which affect usability of the editor
in plaintext mode. apprunner -editor now calls up our editor testbed
with a plaintext (<pre>) document. Many bugs involving things like key
handling, text insertion, selection handling, copy/paste, and inserting
of breaks (when hitting return) have been fixed. Several memory leaks
have also been fixed, to improve performance and decrease memory
footprint."
Current Status
-
Thanks to Bruce Mitchener and Ramiro Estrugo for getting Solaris/gcc 2.7.x/purify working! Look for Bruce's purify reports in mozilla.patches.
- Link clicks aren't working (3553)
- Steve Lamm has greatly improved the Unix build system; see slamm link below, a lot of autoconf reaming.
- Heads-up: We're about to move from {MOZILLA_HOME, .netscape} to {MOZILLA_FIVE_HOME, .mozilla}. (ramiro, mcafee, dp)
Top Issues
- Better handling of GC's (ramiro)
- Decent font support (mcafee)
- Make the build system easier to use (slamm)
- We need a profiler! gprof? quantify? (mcafee)
The bad news is that Jeff Galyan is no longer working on the project.
This week:
- Patches for addressbook lookups being contributed by Mauro Botehlo.
- Edwin's working on making multiple identies stellar.
- I'm working on fixing threading problems with TreeTable.
Coming weeks:
- Document current status of Grendel.
- Identify network/UI integration problems with Grendel.
- Add context sensitive menus.
- Catch up on the work that was being done by Jeff.
Look for the documentation on what's working, what's broken, and
what needs fixing by the end of next week.
Phil Peterson has news regarding the Mail/News client:
"Admin
-
Smoke test
published to mozilla to allow developers and QA to track progress and regressions.
-
First UE spec-lets posted to the mail-news
newsgroup, involving folder organization and multiple identities. Feedback
would be helpful. More UE specs coming soon.
-
We've come a long way towards the M3/Dogfood milestone this week. Details
of our successes and soon-to-be-successes:
What works this week
-
There's an Apps menu in apprunner with a Messenger item. This brings up
mailshell.xul, the main three pane window.
-
Mork DB is checked in and part of the build
-
Mail composition with Ender is enabled
-
On startup, the thread pane loads with real data from the mail folder specified
by threadPane.xul (currently "Inbox").
-
Clicking in the thread pane loads the message pane with local mail
-
Deleting local mail messages marks them deleted in the Berkeley folder
and updates RDF, which updates the tree control.
-
Downloading mail (using GetMsg button) from a POP server works. It's hard-coded
to "leave on server" now, so it won't drain your IMAP inbox.
-
MIME stream converters using new API have landed. Parsers for message/rfc822
and vcards are working.
-
4.x-style menus and toolbars are expressed in XUL, although the only commands
which work are Delete, Get Msg, and New Msg.
What doesn't work but is real close
-
Linux support is a little behind Windows. It may run today, but it may
not. The addition of another engineer soon will help this.
-
Reply/forward may get done before Sunday night, but maybe not.
-
RDF command processing is done using appcores and C++, not scripting the
composite data source.
-
Clicking in the folder pane will probably load the thread pane sometime
later today.
Next week
-
All items in the "real close" list
-
The visual appearance and stability of the app need work.
-
Beginning M4 work, including views in the thread pane, IMAP, and lots of
other stuff TBD on Monday.
Footprint watch: I'm going to try this out and see if it's interesting
enough to keep doing on a weekly basis. This is a little bigger than I
expected; anyone else surprised?
Mail/News disk footprint (optimized code on Win32)
|
Filename
|
What is it?
|
How big is it?
|
| mailnews.dll |
Main mail/news stuff (app core, data sources, DB code, etc.) |
303,104
|
| msglocal.dll |
POP3, local mail |
143,360
|
| msgcompose.dll |
app core for message composition |
311,296
|
| mime.dll |
MIME parser |
335,872
|
| mimect-cal.dll |
MIME converter for vCal |
28,672
|
| mimect-vcard.dll |
MIME converter for vCard |
258,048
|
|
Total |
1,380,352
|
Chris Waterson writes in with this RDF update:
Progress
- Implemented "delete" notifications in the tree builder code, so that (for example) when a message is deleted, the item is actually removed from the tree
control.
- Implemented "re-rooting" of the tree control so that (for example) mail-news can change the contents of the thread pane on demand. There are apparently
still some bugs with this: waiting to hear from alecf or mscott.
- Rolled 4.5 bookmarks parser forward into the SeaMonkey codebase.
- Ironed out command architecture: Warren did most of the heavy lifting on this.
- Landed Guha's history data source into the tree: Robert did a lot of cleanup to get stuff working right on Mac.
- Implemented some of McMullen's filespec stuff to mac bookmark parsing work on Mac (aliases and stuff).
Plans
- Help rickg finish the nsIString interface so that we can get land RDF scriptability.
- Convert RDF to use XPIDL-generated header files; this'll allow RDF to be 100% scriptable.
- Land a bunch of changes that warren had made a couple weeks ago to convert the RDF "cursor" APIs into standard enumerators.
- Lots and lots of DOM APIs to finish off.
Problems
None to report.
Scott writes:
"Thanks to efforts by John
Bandauer, Mike McCabe and Mike Shaver, XPConnect was able to run the
equivalent of 'Hello World' (and more) on March 11. This entailed
compilation of XPIDL into a typelib, reading the contents of the typelib
at run time and using the XPConnect runtime to wrap XPCOM instances and
perform invocation and argument conversion, etc."
Previous Updates
|