Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Reminder of security branch tree rules: do not check in without explicit approval

3 views
Skip to first unread message

Daniel Veditz

unread,
Jun 12, 2009, 12:02:02 AM6/12/09
to
The stable security update branches have a simple consistent tree rule
that is clearly posted at the top of the branch tinderbox (which you all
check for green before checking in, right?): do not check in without
explicit approval for that release.

We have overlapping development and QA periods and assign many bugs to
blocking the next release while we're still finishing up the last one.
If we've done that we don't want that patch landing while we're
verifying the release in progress. And we do need to check patches for
special branch coding rules that the original reviewers didn't have to
worry about, such as not changing shipped interfaces to avoid breaking
addons.

So please, do not check into the 1.8, 1.9.0 or soon 1.9.1 branches
without explicit approval on the patch, even for blocking bugs. The tree
rules are always on or clearly linked from the relevant tinderbox for
each release branch.

Thank-you,
-Dan Veditz

Ted Mielczarek

unread,
Jun 12, 2009, 9:05:33 AM6/12/09
to Daniel Veditz, dev-pl...@lists.mozilla.org
I assume the blanket approval for porting tests still applies? For 1.9.1, up
to this point, we've also been extending this to cover changes in test
harnesses, since that makes everyone's lives easier in backporting tests to
the stable branches.

-Ted

Daniel Veditz

unread,
Jun 12, 2009, 7:18:29 PM6/12/09
to Ted Mielczarek

You always need an explicit "these files are ok for this branch" from
someone. If the files are NPOTB then that person could be the module
owner rather than release-drivers, but it needs to be explicit with
branch considerations taken into account.

A review that says something is OK to land on trunk where it will get
beat on for months before shipping may not have been done to the same
criteria as landing code on a branch where we're never more than a
couple of weeks from shipping to a hundred million users. Not only do
1.9.0 branch changes not get much time for testing we've got an order of
magnitude fewer nightly users than trunk/1.9.1

You also need to be aware of the schedule so you're not landing changes
when we're trying to lock it down.

But other than all that, tests are good :-)

-Dan

0 new messages