M13 Builds Appearing
Friday December 17th, 1999
Mozilla has improved greatly over the past two weeks, so if you haven't checked it out, try to pick up a copy of the release when it hits the ftp site.
#24 See n.p.m.seamonkey post
Saturday December 18th, 1999 10:00 AM
You are replying to this message
Here's part of what Jim A. Roskind had to say on n.p.m.seamonkey (this past Thursday morning).
Warning: The following represent my personal opinions, and the plans of a pile of Netscape contributors, and are not necessarilly that of the entire mozilla community. I can always hope that the plans will make sense to a lot of folks, and that they'll join us in this portion of the plan... but we're not mandating any of this outside the Netscape staff. I'm trying to combine both status, our plans, and some motivation for our startegy, and if I say something in a less than PC way, please at least flame me privately ;-).
We're now planning to branch for M12 on Thursday morning.
We haven't reached "engineering dogfood," but we're pretty close
Tree will probably partially open (post M12 branch) Thursday afternoon, but Netscapers will continue to act under an "approval required" rule till we reach dogfood.
With regard to *M12*:
We shut the tree down last Tuesday eve, 12/7, as part of an effort to produce a monthly stability checkpoint (M12). During the week we restricted our checkins to fixes for serious regression, *really* low risk items, and major usabality issues (where we had a strong handle on the risk of the fix). The bulk of the checkins centered on major usability bugs called PDT+ Dogfood bugs (discussed in next paragraph). The usability of the product went way up, and the stability also increased over the course of the week (last Sunday was a great build for me... I ran for many hours doing work). We had planned on branching for M12 today, but a last minute regression (landed Monday afternoon) stalled the closing actions, and we'll now branch tomorrow morning. We expect to do some verification on M12, fix any critical regressions that cheated thier way in, and then stamp M12 as done (I've heard rumors about Mozilla creating an alpha around M12... but that will be the topic of other email ;-) ).
A reasonable review of *dogfood*:
Our current near term goal has been to get do "dogfood" here at Netscape with Seamonkey. We defined dogfood as the ability to do browsing, reading and sending messages (the basic stuff that most folks do with such a product). Most critically, we were looking only for barely edible dogfood (goes back to the words of wisdom: "learn to eat the dogfood you produce"). We were willing to accept a lot of work-arounds and avoidance maneuvers to use the product (example: don't use the file->open dialog, just enter the URL in the URL box). We had a team of managers (Product Delivery Team, or PDT) triaging bugs that had the word "dogfood" in the summary, and agreeing the bug was a "significant usage stopper," or deciding that it could be worked around. Usage stoppers were marked PDT+ in the whiteboard, and less broadly critical bugs were labeled PDT-.
Simply put, the reason for striving so hard for dogfood is to get the entire engineering staff at Netscape using the product, day in and day out. History tells us that once we reach this critical milestone, that the quality of the product will be held consistently higher, and that critical bugs will get the attention they need much sooner (in part because they are discovered sooner, and in part because of peer pressure when a feature regression impacts your coworkers).
Progress review towards *dogfood*
Over the past several weeks we've driven down these PDT+ bugs (by fixing some bugs as new ones were found and injected). The count went on a weekly basis from 120, to 96, to 107, then 85, 73, 63, and most recently, on last Sunday night, to 40. Our objective goal (pulled gracefully from the air) was to get down to a mere 5 PDT+ bugs, and then "call it dogfood" (and presumably note that most of the development staff is using the product, most of the time (eating Mozilla's dogfood)). Not only was the last week spectacularly effective (going from 63 to 40, or a week's reduction of 23 PDT+ bugs), but this week has proved an even more agressive follow on. We are currently around 22 PDT+ bugs (do a query for "dogfood" in the summary, and "PDT+" in the whiteboard to see this list), and it is "only" Wednesday night of the week :-).
While we've made spectacular progress, the folks on the PDT (which includes me) have become nervous about our "count of 5" criteria, and are willing to settle for the subjective criteria that at least "50% of the local developmement staff use the product for at least 50% of their daily work.". Today in a Netscape Client development meeting, in excess of 50% of the attendees reported using the product more than 2 hours per day, but only about 25% were (as yet) using it more than 4 hours a day. We have high hopes that by next Wednesday we'll be "dogfood" by at least one of our criteria... and so we're going to continue to try to get there RSN.
Given the proximity that we have to the holiday's, and the desire to be consistent in our monthly checkpoint releases, we've decided to release M12 on schedule, and move forword with the plan given below. There is a big difference in purpose between our "dogfood milestone" and the "M12 Stability Checkpoint." One represents a feature status, the other is somewhat akin to a daily verification build. We expect that folks will "like" the M12 build a lot, but we don't want to delay that sample point waiting for the status we're nearing with dogfood.
Plan and strategy going foward:
Netscape engineers will continue to give a _very_ high priority to PDT+ dogfood bugs, and try to drive this count to "zarro boogs" (a programmer's approximation of zero bugs). The good news is that with only about 22 PDT+ bugs remaining, the number of critically involved engineers should be relatively small We'll live on the tip getting checkin permission from chofmann (with jar and brendan as backup approvers). The restrictions will allow folks to begin work towards beta, but will try extra hard to prevent regressions which would preclude reaching dogfood. The checkin approval, and carefully monitored carpool landings as appropriate, should help maintain stability long enough for us to hit dogfood (...at least that's the theory :-/ ).Engineering managers will continue to help focus their staff on these critical PDT+ dogfood bugs... and hopefully, we'll be there in no time (I'm guessing that we'll be there by Wednesady of next week :-) ... but I can't promise).
When we reach dogfood, we'll drop back to our standard "open tree" requiring only code review and bug numbers in the checkin log, along with the running of the smoke test. Here again we hope that we'll stay real near dogfood even as we see additional landings, or at least we'll correct back to dogfood ASAP when we err.
Our current plan calls for the next stability checkpoint to have a tree closure at midnight, Monday night, January 17th. We feel confident that January's M13 will be a checkpoint with quality well above that of dogfood :-).
If you like what folks at Netscape are doing, we would ask that you join us in getting approval for your checkins from <email@example.com> (or <firstname.lastname@example.org>, or <email@example.com>). We believe it is in the best interest of the seamonkey project to reach dogfood asap, and get on with developing the product, while we live and browse in the code. If you're using Seamonkey now, you'll be able to tell (looking up at the mail header, even if you have "brief format" set), that I wrote and composed this in Seamonkey. I hope you'll join us in both eating the dogfood, and making it taste better, run faster, and jump higher.
Hope that answers at least part of your question.