• We managed to filter out the bad bugs.
• The quality of the patches was of high enough quality that stability wasn't affected because of the quality of engineering work.
• People who are working on major changes are using branches, making test builds which are being run through QA and are catching big regressions first.
• People were self-policing themselves and didn't bother trying to send us high-risk patches because they knew of the drivers barrier.
The types of bugs that engineers have been working on have been inherently low risk.

Personally, I think that's it's a combination of all of these factors with varying degrees of importance.

Anyway, enough with talking about the past. Let's talk about what we want to do in the future.

For the 0.9.2 branch:

We will, as we have for the last several milestones, use drivers as the approval point for the 0.9.2 branch. This is an important milestone to Mozilla.org and some vendors so we will be focusing on stability, leaks and major usability issues. We still have a lot of triaging work left to do before we know what the timeframe will be for a Mozilla 0.9.2 release at this point.

We will be taking only very low risk, very high yield patches for this branch and we intend to release quickly. Also, we expect that Netscape will be doing some kind of release off of the 0.9.2 branch. After the Mozilla release of 0.9.2 Netscape will continue making fixes on the 0.9.2 branch.

We are going to give Netscape complete control over that branch for their release. This means that Netscape gets to decide what goes into that branch after we tag our release. Once Netscape releases something off of that branch we will be doing a release numbered 0.9.2.1 based on that code.

For the trunk, post 0.9.2 branch until 0.9.3:

After 0.9.2 has been cut we will return to the model we used before the 0.9.2 cycle. When the trunk is open for regular checkins you will not be required to ask for approval from drivers to check in your code. You will only need the usual review, module owner approval and super-review. ( I can hear the cheers now. )

Of course if the quality of the code checked into the trunk deteriorates noticeably, we'll do something. We might reinstate the 'a=' requirement, maybe something else. We haven't figured this out yet because we're hoping it won't be necessary.

Please take extra care with the trunk after the 0.9.2 branch is cut. It is critical that we keep the stability that we have maintained over the last few weeks and the best way to do that is to make sure that it is prevalent in the minds of everyone doing development, QA and reviewing. If you think that there might be problems with your patch or you feel it hasn't been tested enough then don't check it in. We're not breathing down your neck to get it in. And if you do have a large, high risk patch make sure you've created test builds and have run them through QA first. We won't be feeling very friendly if you don't.

There may be times when a patch is important enough that we'll want to risk stability to get it in. We expect this to happen on the way to Mozilla 1.0. Don't make this decision yourself. Get drivers@mozilla.org involved.

We can try to maintain quality through processes such as the 'a=' requirement. We'd rather not. We'd prefer to have the people who make up drivers@mozilla.org working on the code itself, rather than reviewing every check-in. This allows faster overall progress, and makes everyone's life easier. To do this and maintain the quality that we have right now requires each person to be his or her own police force.

Thanks to everyone who helped make the ride from 0.9.1 to 0.9.2 a very pleasant one indeed. Help us do the same for the ride to 0.9.3.