0.9.2 Branch and Beyond
The tree did manage to maintain the same quality of the time right before the release of the 0.9.1 milestone. However, we think that it wasn't because of the fact that drivers were approving specific bugs. With only a few specific exceptions we approved almost every bug that came across our collective plate. There are a few possible explanations for the continuing stability:
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
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
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 email@example.com 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
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.
Got a response? TalkBack!