M8 Checkin Rules
Mike Connor
On the browser/toolkit the tree is still considered open, as the feature
freeze for the front end is targeted at M8.
For Gecko, the following checkin rules will apply.
* Any remaining Gecko features require explicit driver approval.
* All non-feature blockers have blanket approval for checkin.
* All non-feature patches already marked as [wanted-1.9] by drivers also
have blanket approval until August 22 (two weeks before M8 freeze).
After August 22nd, explicit driver approval will be required for
wanted-1.9 patches, although this status will be considered by drivers.
* All other patches will require explicit approval starting from the
tree reopening.
There will be an approval1.9 flag added to Bugzilla before the tree reopens.
Any concerns?
-- Mike
L. David Baron
> * All other patches will require explicit approval starting from the
> tree reopening.
I think going immediately from large feature crash landings to
requiring approvals doesn't make sense. We should gradually ramp
things down; otherwise we'll lose a lot of the simple (low cost and
low benefit, for reasonable ratio) cleanups and fixes because the
approval regime will raise the cost too high for people to bother.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Mike Connor
> On Friday 2007-07-27 22:09 -0400, Mike Connor wrote:
>
>> * All other patches will require explicit approval starting from the
>> tree reopening.
>>
>
> I think going immediately from large feature crash landings to
> requiring approvals doesn't make sense. We should gradually ramp
> things down; otherwise we'll lose a lot of the simple (low cost and
> low benefit, for reasonable ratio) cleanups and fixes because the
> approval regime will raise the cost too high for people to bother.
>
I'm not sure I care about losing some low benefit fixes. We have at
least 550 bugs that we've already flagged as something we want to get
into 1.9, so I think the time is past for code cleanup. I also don't
think the approval process is much more onerous than going through r+sr,
especially if reviewers can take a moment to comment on risk/benefit.
-- Mike
Mike Schroepfer
>
> I think going immediately from large feature crash landings to
> requiring approvals doesn't make sense. We should gradually ramp
> things down; otherwise we'll lose a lot of the simple (low cost and
> low benefit, for reasonable ratio) cleanups and fixes because the
> approval regime will raise the cost too high for people to bother.
Understand the concern. Is this mitigated by the fact that all blockers
and wanted-1.9 don't go through normal approvals? E.g. if it gets on
the blocker list we are good to go...
best,
Schrep
timeless
tree with this planning. We have probably 50-100 tiny patches. It's
hard enough splitting patches out of a messy patch set into distinct
bugs explaining what each fix is and does. there's no way I can
justify writing explanations for why I want to upstream patches for
each of them.
That said, it seems pretty clear that no one cares. So lump me into
that category. If dougt wants to upstream our patches, he's welcome to.
Jean-Marc Desperrier
> L. David Baron wrote:
>> On Friday 2007-07-27 22:09 -0400, Mike Connor wrote:
>>
>>> * All other patches will require explicit approval starting from the
>>> tree reopening.
>>>
>>
>> I think going immediately from large feature crash landings to
>> requiring approvals doesn't make sense. We should gradually ramp
>> things down; otherwise we'll lose a lot of the simple (low cost and
>> low benefit, for reasonable ratio) cleanups and fixes because the
>> approval regime will raise the cost too high for people to bother.
>>
> Given where we are on blockers (328), noms (225), and wanted-1.9 (229),
> I'm not sure I care about losing some low benefit fixes. We have at
> least 550 bugs that we've already flagged as something we want to get
> into 1.9, so I think the time is past for code cleanup.
I think the concern might be not so much about not having them in 1.9
than having a very long time period during which it will be impossible
to check them in until 1.9 branches.
> I also don't
> think the approval process is much more onerous than going through r+sr,
> especially if reviewers can take a moment to comment on risk/benefit.
Can you do anything to ensure it will be the case ? Or just check what
really happens.
Mike Connor
> I think the concern might be not so much about not having them in 1.9
> than having a very long time period during which it will be impossible
> to check them in until 1.9 branches.
>
What's a very long time here? A month or two doesn't seem quite seem
that long, in proportion to the length of the development cycle (and
that of the projected Mozilla 2 cycle). Are there going to be a lot of
people working on fixes for random bugs, vs. helping out with the large
set of blocker/wanted bugs? Is it worth splitting our nightly tester
community (or worse, not having sufficient nightly users on the new
trunk to catch regressions) to get a small head start on random bugfixes
for Mozilla 2?
>> I also don't
>> think the approval process is much more onerous than going through r+sr,
>> especially if reviewers can take a moment to comment on risk/benefit.
>>
>
> Can you do anything to ensure it will be the case ? Or just check what
> really happens.
We can remind reviewers to note risk as appropriate, but I can't ensure
that reviewers will do so.
-- Mike
Jean-Marc Desperrier
> Jean-Marc Desperrier wrote:
>> I think the concern might be not so much about not having them in 1.9
>> than having a very long time period during which it will be impossible
>> to check them in until 1.9 branches.
>
> What's a very long time here? A month or two doesn't seem quite seem
> that long, in proportion to the length of the development cycle (and
> that of the projected Mozilla 2 cycle).
Let's keep cool and clarify any miscomprehension here.
My comprehension was a much longer period than that.
I didn't see, maybe I just missed it, anything about 1.9 branching in a
month or two.
Are you really implying it will branch that soon ?
There's already a M9 planified for Oct 15, and more to come after that.
That would mean a very long period of branching, and I believe the last
time this kind of things happened left everybody bad rememberings.
>>> I also don't think the approval process is much more onerous than
>>> going through r+sr, especially if reviewers can take a moment to
>>> comment on risk/benefit.
>>
>> Can you do anything to ensure it will be the case ? Or just check what
>> really happens.
>
> We can remind reviewers to note risk as appropriate, but I can't ensure
> that reviewers will do so.
That's already good to discuss with them about that, and maybe also tell
people to raise their voice here if in practice the requirement causes
numerous patches to get stalled.
Benjamin Smedberg
> Understand the concern. Is this mitigated by the fact that all blockers
> and wanted-1.9 don't go through normal approvals? E.g. if it gets on
> the blocker list we are good to go...
I don't really understand the difference... module owners can put basically
anything on the wanted-1.9 list that they decide is risk-reward-worthy, right?
I tend to think that the policy should be "patch risk should be considered
by module owners during the review process; all new features require driver
approval".
--BDS
Mike Connor
On 30-Jul-07, at 12:30 PM, Benjamin Smedberg wrote:
> Mike Schroepfer wrote:
>
>> Understand the concern. Is this mitigated by the fact that all
>> blockers
>> and wanted-1.9 don't go through normal approvals? E.g. if it gets on
>> the blocker list we are good to go...
>
> I don't really understand the difference... module owners can put
> basically
> anything on the wanted-1.9 list that they decide is risk-reward-
> worthy, right?
No, that's a driver status. I would ask that people don't abuse that
to do an end run on the policy or we'll have to add a custom field...
> I tend to think that the policy should be "patch risk should be
> considered
> by module owners during the review process; all new features
> require driver
> approval".
We've really held off on restricting checkins until now, but I don't
believe that we're going to get all module owners on the same page
for mitigating risk. Driver control has proven to be an effective
method for getting releases wrapped up, and I think we're at the
point where we need to start doing this. Is this based on a concern
around driver workload/roadblocking, or because you think we should
have a higher tolerance for risk than driver control generally means?
-- Mike
Benjamin Smedberg
> No, that's a driver status. I would ask that people don't abuse that to
> do an end run on the policy or we'll have to add a custom field...
ok, maybe I misunderstand "driver" here. I am the driver for
toolkit/xpcom/platform stuff, right? So I have the right to mark the bugs
[wanted-1.9]?
> We've really held off on restricting checkins until now, but I don't
> believe that we're going to get all module owners on the same page for
> mitigating risk. Driver control has proven to be an effective method
> for getting releases wrapped up, and I think we're at the point where we
> need to start doing this. Is this based on a concern around driver
> workload/roadblocking, or because you think we should have a higher
> tolerance for risk than driver control generally means?
I am concerned about both:
1) driver workload: are you talking about the divided-up-by-module drivers?
If so, I know that neither Boris nor I has the time to triage the multitude
of nominations that would ensue from this policy. If not, I don't believe
that the small group of drivers will have the ability to respond effectively
to the amount of nominations that would occur.
There are numerous minor regressions from the recent feature freeforall: we
should impose the minimum amount of overhead consistent with maintaining
stability.
2) risk analysis: there are a whole class of bugs that people have not been
nominating for blocking because they wouldn't actually block a Firefox
release, but are nevertheless important, for other apps (tbird, XR apps,
extensions, whatever). I don't think we're at the point yet where we need to
clamp down tightly on these kinds of changes: we're 3.5 weeks from a beta.
3) I am also concerned about the statement "I don't believe that we're going
to get all module owners on the same page for mitigating risk." I'm not
saying that the owners have to help draft the tree rules for freeze, but we
should be able to trust owners to enforce the rules. Drivers should
promulgate a reasonable set of rules/guidelines for acceptable risk and ask
module owners to follow those guidelines. If we really can't trust module
owners to follow those rules, then we have a organizational/communication
problem.
--BDS
Mike Connor
> Mike Connor wrote:
>
>
>> No, that's a driver status. I would ask that people don't abuse that to
>> do an end run on the policy or we'll have to add a custom field...
>>
>
> ok, maybe I misunderstand "driver" here. I am the driver for
> toolkit/xpcom/platform stuff, right? So I have the right to mark the bugs
> [wanted-1.9]?
>
This is a fuzzy line, since we'll have a smaller group (members were
proposed by schrep) in the end game.
For M8 I would expect that the large driver group would continue to have
this authority wrt triage. The smaller 1.9 driver group will take on
approvals.
>> We've really held off on restricting checkins until now, but I don't
>> believe that we're going to get all module owners on the same page for
>> mitigating risk. Driver control has proven to be an effective method
>> for getting releases wrapped up, and I think we're at the point where we
>> need to start doing this. Is this based on a concern around driver
>> workload/roadblocking, or because you think we should have a higher
>> tolerance for risk than driver control generally means?
>>
>
> I am concerned about both:
>
> 1) driver workload: are you talking about the divided-up-by-module drivers?
> If so, I know that neither Boris nor I has the time to triage the multitude
> of nominations that would ensue from this policy. If not, I don't believe
> that the small group of drivers will have the ability to respond effectively
> to the amount of nominations that would occur.
>
I was thinking that the small driver group would take on the approval
queue. It'd probably be about 20-30 bugs a day for now, as people
finish things up, but that number always goes down as we decrease our
risk tolerance.
Approvals at this stage are fairly straightforward, and not massively
time consuming. Beltzner and I triaged 23 nominations in 35 minutes
today, approvals are usually that quick.
> There are numerous minor regressions from the recent feature freeforall: we
> should impose the minimum amount of overhead consistent with maintaining
> stability.
>
> 2) risk analysis: there are a whole class of bugs that people have not been
> nominating for blocking because they wouldn't actually block a Firefox
> release, but are nevertheless important, for other apps (tbird, XR apps,
> extensions, whatever). I don't think we're at the point yet where we need to
> clamp down tightly on these kinds of changes: we're 3.5 weeks from a beta.
>
We're running at 3-5 times the blocker list we've traditionally had
going into beta (500ish all told right now, with 220 Gecko noms
outstanding). I think we're past the point where we should be clamping
down if we're serious about shipping 1.9 in the next year.
http://tinyurl.com/2ju4hu is the set of Core/Toolkit bugs fixed in the
last two weeks that weren't blockers or wanted. On one level, 215 bugs
seems like a fantastic number, but it represents a lot of churn on
lower-priority items. Churn causes regressions (at varying rates)
increasing the amount of work to do in the end game.
> 3) I am also concerned about the statement "I don't believe that we're going
> to get all module owners on the same page for mitigating risk." I'm not
> saying that the owners have to help draft the tree rules for freeze, but we
> should be able to trust owners to enforce the rules. Drivers should
> promulgate a reasonable set of rules/guidelines for acceptable risk and ask
> module owners to follow those guidelines. If we really can't trust module
> owners to follow those rules, then we have a organizational/communication
> problem.
>
Rules are interpreted in different ways, especially in terms of
tolerance for risk. We've found from Fx1.5 and Fx2 that the smaller the
group is, the easier it is to get to a shared comprehension of risk
tolerance.
-- Mike
Mike Connor
On 30-Jul-07, at 8:12 AM, Peter Weilbacher wrote:
> Will there be a 1.9 branch in CVS to go along with the approved
> patches
> as for 1.8? When?
Hopefully not. The goal is to open the Moz2 trunk in Hg, since any
other path will result in wasted effort.
> How do you suggest to handle OS/2 stuff? Asking approval for all the
> fixes that we have to do after all the breakages of the last two
> weeks,
> and for the ongoing work on Thebes would slow us down even more. OS/2
> work rarely touches cross-platform files (other than build config)
> in a
> non-trivial manner, so I hope you can grant us general approval for
> that.
For anything OS/2 only I think we'd have a blanket approval at this
point.
-- Mike
Mike Schroepfer
Why do you say that no one cares? We are having a discussion here about
most effective way to land changes and control risk. The last two major
releases went into driver control around this time - so everyone is just
trying to find the right balance between risk and overhead here...
Mike
Aaron Leventhal
for 1.9, because we're simply trying to fix as many Linux ATK, ARIA and
IAccessible2 bugs as we can before release. At this point we're not trying to
add features.
We can go through and mark the bugs ahead of time that we still want for the
release. But, I doubt that drivers will appreciate a flood of blocking1.9? flags
from the mozilla/accessible module. Especially since drivers may not be in a
great position to research every accessibility bug.
Should we just ask for a='s piecemeal as we go? Or is there some way we can work
efficiently on this?
How would drivers prefer we proceed?
- Aaron
L. David Baron
> Approvals at this stage are fairly straightforward, and not massively
> time consuming. Beltzner and I triaged 23 nominations in 35 minutes
> today, approvals are usually that quick.
What approvals were you triaging? The patches I'd like to request
approval for don't have an approval flag that I can request. It
might be more time-consuming once people can request approval.