M8 Freeze Now In Effect
Damon Sicore
The M8 code freeze is now in effect. Tree is closed. Explicit
driver approval required for all checkins. Thanks go to everyone who
worked so hard to get those last minute patches in. :)
Cheers,
Damon
smaug
> All,
>
> The M8 code freeze is now in effect. Tree is closed. Explicit driver
> approval required for all checkins.
Does that mean "all checkins which changes code for Firefox (gecko,
toolkit, etc)" or really "all". XForms is not part of the build and I
wonder what the policy is there, and what happens after M8. Do XForms
patches need approval?
-S
Peter Weilbacher
> Damon Sicore wrote:
>> The M8 code freeze is now in effect. Tree is closed. Explicit driver
>> approval required for all checkins.
>
> Does that mean "all checkins which changes code for Firefox (gecko,
> toolkit, etc)" or really "all". XForms is not part of the build and I
> wonder what the policy is there, and what happens after M8. Do XForms
> patches need approval?
I'm a bit confused, too. I would like to check in a few more things only
affecting OS/2 which, as we agreed before, don't need approval. But as the
tree is now marked as closed in addition to the red threat level, I am not
sure what to do. (I had understood the earlier messages that the threat
level would be turned to red and the tree would stay "open" and only be
closed a short time for release tagging. But that could have been my own
interpretation.)
Peter.
Damon Sicore
Hi, Guys. I think this topic was covered in the dev-planning thread
here:
http://preview.tinyurl.com/2jdolv
Specifically:
> > Also, are we explicitly stating that checkins that are not part
> of the
> > Firefox default build are exempt from these requirements (this
> includes
> > port-specific work for OS/2, photon, etc)?
>
> Yes - should have said that explicitly. Has been is and is still
> true.
Does that help clear up your concerns?
Cheers,
Damon
>
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Peter Weilbacher
> Hi, Guys. I think this topic was covered in the dev-planning thread
> here:
>
> http://preview.tinyurl.com/2jdolv
>
> Specifically:
>
>
>> > Also, are we explicitly stating that checkins that are not part of the
>> > Firefox default build are exempt from these requirements (this includes
>> > port-specific work for OS/2, photon, etc)?
>>
>> Yes - should have said that explicitly. Has been is and is still
>> true.
>
> Does that help clear up your concerns?
Well, partly. That thread was about threat levels and never mentioned that
with the red level the tree would be marked "closed" (which in the past
was always an indicator to not check in anything at all). But as you are
pointing us to that posting again, I will just take that to say that I can
ignore that in the future, too (for OS/2 only stuff). :-)
Peter.
Robert Kaiser
> Damon Sicore wrote:
>> Does that help clear up your concerns?
>
> Well, partly. That thread was about threat levels and never mentioned that
> with the red level the tree would be marked "closed" (which in the past
> was always an indicator to not check in anything at all). But as you are
> pointing us to that posting again, I will just take that to say that I can
> ignore that in the future, too (for OS/2 only stuff). :-)
We already had extensive CLOSED phases in the past on trunk where it
only meant "closed for anything that touches default Firefox builds" and
others were still free to check in.
Robert Kaiser
L. David Baron
> sure what to do. (I had understood the earlier messages that the threat
> level would be turned to red and the tree would stay "open" and only be
> closed a short time for release tagging. But that could have been my own
> interpretation.)
Agreed.
In the past, I thought we'd come to the conclusion that using the
bonsai CLOSED state to mean that only approved checkins were allowed
meant there wasn't a state to say that the tree was closed for
tagging or bustage.
Should the tree instead say OPEN but frozen, with documentation that
only driver-approved checkins are allowed?
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Robert O'Callahan
> In the past, I thought we'd come to the conclusion that using the
> bonsai CLOSED state to mean that only approved checkins were allowed
> meant there wasn't a state to say that the tree was closed for
> tagging or bustage.
>
> Should the tree instead say OPEN but frozen, with documentation that
> only driver-approved checkins are allowed?
Yes, absolutely it should. We just had a discussion about this on IRC
--- I have an M8-approved patch, but while the tree is closed I have
no way of telling whether it's OK to land or not (it might not be OK
to land if Tinderbox was showing performance regressions, or a
scheduled landing was about to happen, etc).
Rob
Damon Sicore
The outcome of the IRC discussion was that I reopen the tree, mconnor
is going to coordinate landing slots with the sheriff at the time,
and the tree will close during the landing slotting period. At that
point, the Sheriff will be the person to coordinate the landings,
explicitly.
Just to be clear: After the landing slots are completed, the tree
will remain closed, tinderboxen will cycle, and then mconnor will
notify release-drivers@ once there is a green light.
Concerns/suggestions/thoughts?