Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Johnathan Nightingale
Howdy folks,

The new Fennec is getting close to beta quality. We're taking down the remaining beta blockers[1] and hope to push it in the next few weeks. As with major desktop releases in the pre-train days, we feel a lot of pressure to lock this one down and get it out the door. Part of this pressure is internal, because we are getting close and we can feel it and we don't want any surprises. Part of it is external because it's really much better than the XUL fennec currently in the market, and we want to get these improvements out to users.

Fennec is based on Gecko 14, which is still on mozilla-central for another 9 days. I'd like to ask that we move mozilla-central to APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk of a late-landing change breaking Fennec. I'd propose that desktop-only changes get swift approval, and that we should have daily triage for all other requests to ensure we don't introduce too much drag.

I know it's a bit weird, since the last year of train-based releases has seen mozilla-central open almost continuously. I think this is a pretty rare event, though, and that Fennec needs the help reducing risk wherever possible. Once it is out the door, we'll get Fennec back on the trains so that we don't have this kind of dependency.

We discussed a few other options on release-drivers (migrate to Aurora early, put mobile development on other branches, do nothing) but each seemed like a worse outcome to me than using the APPROVAL_REQUIRED hook we already have. We can get the flag added today, but first I want to know whether there are any deal-breaker concerns with this proposal.

Thanks,

Johnathan

[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec1.0:beta

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
@johnath

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Ehsan Akhgari
What will the approval flag triage process look like?  I remember than for
a while during the Firefox 4 development, the approval flag was not triaged
actively because of the sheer volume unless one pinged somebody on the
release drivers team.  Is there going to be daily triages so that
developers can be sure that every patch they mark for approval will be
looked at within, let's say, a day?

Thanks!
--
Ehsan
<http://ehsanakhgari.org/>


On Mon, Apr 16, 2012 at 10:56 AM, Johnathan Nightingale <[hidden email]
> wrote:

> Howdy folks,
>
> The new Fennec is getting close to beta quality. We're taking down the
> remaining beta blockers[1] and hope to push it in the next few weeks. As
> with major desktop releases in the pre-train days, we feel a lot of
> pressure to lock this one down and get it out the door. Part of this
> pressure is internal, because we are getting close and we can feel it and
> we don't want any surprises. Part of it is external because it's really
> much better than the XUL fennec currently in the market, and we want to get
> these improvements out to users.
>
> Fennec is based on Gecko 14, which is still on mozilla-central for another
> 9 days. I'd like to ask that we move mozilla-central to APPROVAL_REQUIRED
> for the next 9 days so that we can reduce the risk of a late-landing change
> breaking Fennec. I'd propose that desktop-only changes get swift approval,
> and that we should have daily triage for all other requests to ensure we
> don't introduce too much drag.
>
> I know it's a bit weird, since the last year of train-based releases has
> seen mozilla-central open almost continuously. I think this is a pretty
> rare event, though, and that Fennec needs the help reducing risk wherever
> possible. Once it is out the door, we'll get Fennec back on the trains so
> that we don't have this kind of dependency.
>
> We discussed a few other options on release-drivers (migrate to Aurora
> early, put mobile development on other branches, do nothing) but each
> seemed like a worse outcome to me than using the APPROVAL_REQUIRED hook we
> already have. We can get the flag added today, but first I want to know
> whether there are any deal-breaker concerns with this proposal.
>
> Thanks,
>
> Johnathan
>
> [1]
> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec1.0:beta
>
> ---
> Johnathan Nightingale
> Sr. Director of Firefox Engineering
> @johnath
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Ehsan Akhgari
Well, I need to work on my reading comprehension skills.  Or my attention
deficit disorder.  Or both!

"I'd propose that desktop-only changes get swift approval, and that we
should have daily triage for all other requests to ensure we don't
introduce too much drag."

--
Ehsan
<http://ehsanakhgari.org/>


On Mon, Apr 16, 2012 at 11:17 AM, Ehsan Akhgari <[hidden email]>wrote:

> What will the approval flag triage process look like?  I remember than for
> a while during the Firefox 4 development, the approval flag was not triaged
> actively because of the sheer volume unless one pinged somebody on the
> release drivers team.  Is there going to be daily triages so that
> developers can be sure that every patch they mark for approval will be
> looked at within, let's say, a day?
>
> Thanks!
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
>
> On Mon, Apr 16, 2012 at 10:56 AM, Johnathan Nightingale <
> [hidden email]> wrote:
>
>> Howdy folks,
>>
>> The new Fennec is getting close to beta quality. We're taking down the
>> remaining beta blockers[1] and hope to push it in the next few weeks. As
>> with major desktop releases in the pre-train days, we feel a lot of
>> pressure to lock this one down and get it out the door. Part of this
>> pressure is internal, because we are getting close and we can feel it and
>> we don't want any surprises. Part of it is external because it's really
>> much better than the XUL fennec currently in the market, and we want to get
>> these improvements out to users.
>>
>> Fennec is based on Gecko 14, which is still on mozilla-central for
>> another 9 days. I'd like to ask that we move mozilla-central to
>> APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk of a
>> late-landing change breaking Fennec. I'd propose that desktop-only changes
>> get swift approval, and that we should have daily triage for all other
>> requests to ensure we don't introduce too much drag.
>>
>> I know it's a bit weird, since the last year of train-based releases has
>> seen mozilla-central open almost continuously. I think this is a pretty
>> rare event, though, and that Fennec needs the help reducing risk wherever
>> possible. Once it is out the door, we'll get Fennec back on the trains so
>> that we don't have this kind of dependency.
>>
>> We discussed a few other options on release-drivers (migrate to Aurora
>> early, put mobile development on other branches, do nothing) but each
>> seemed like a worse outcome to me than using the APPROVAL_REQUIRED hook we
>> already have. We can get the flag added today, but first I want to know
>> whether there are any deal-breaker concerns with this proposal.
>>
>> Thanks,
>>
>> Johnathan
>>
>> [1]
>> https://bugzilla.mozilla.org/buglist.cgi?quicksearch=blocking-fennec1.0:beta
>>
>> ---
>> Johnathan Nightingale
>> Sr. Director of Firefox Engineering
>> @johnath
>>
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
>>
>
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Jonathan Kew-3
In reply to this post by Johnathan Nightingale
On 16/4/12 15:56, Johnathan Nightingale wrote:

> Howdy folks,
>
> The new Fennec is getting close to beta quality. We're taking down
> the remaining beta blockers[1] and hope to push it in the next few
> weeks. As with major desktop releases in the pre-train days, we feel
> a lot of pressure to lock this one down and get it out the door. Part
> of this pressure is internal, because we are getting close and we can
> feel it and we don't want any surprises. Part of it is external
> because it's really much better than the XUL fennec currently in the
> market, and we want to get these improvements out to users.
>
> Fennec is based on Gecko 14, which is still on mozilla-central for
> another 9 days. I'd like to ask that we move mozilla-central to
> APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk
> of a late-landing change breaking Fennec. I'd propose that
> desktop-only changes get swift approval, and that we should have
> daily triage for all other requests to ensure we don't introduce too
> much drag.
>
> I know it's a bit weird, since the last year of train-based releases
> has seen mozilla-central open almost continuously. I think this is a
> pretty rare event, though, and that Fennec needs the help reducing
> risk wherever possible. Once it is out the door, we'll get Fennec
> back on the trains so that we don't have this kind of dependency.
>
> We discussed a few other options on release-drivers (migrate to
> Aurora early, put mobile development on other branches, do nothing)
> but each seemed like a worse outcome to me than using the
> APPROVAL_REQUIRED hook we already have. We can get the flag added
> today, but first I want to know whether there are any deal-breaker
> concerns with this proposal.

Could you clarify how you expect trees that regularly merge to m-c (in
particular, mozilla-inbound) to operate during this period? Should we
assume such merges will be suspended (although individual approved
patches might be transplanted), or should inbound *also* be made
APPROVAL_REQUIRED, or what?

Thanks,

JK
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Johnathan Nightingale
On Apr 16, 2012, at 12:19 PM, Jonathan Kew wrote:

>> We discussed a few other options on release-drivers (migrate to
>> Aurora early, put mobile development on other branches, do nothing)
>> but each seemed like a worse outcome to me than using the
>> APPROVAL_REQUIRED hook we already have. We can get the flag added
>> today, but first I want to know whether there are any deal-breaker
>> concerns with this proposal.
>
> Could you clarify how you expect trees that regularly merge to m-c (in particular, mozilla-inbound) to operate during this period? Should we assume such merges will be suspended (although individual approved patches might be transplanted), or should inbound *also* be made APPROVAL_REQUIRED, or what?


I'd be interested in thoughts, really. The approval required hook will bounce pushes without a= (whether on each changeset or just the topmost, I don't remember) so by default, I think mozilla-inbound would be de facto APPROVAL_REQUIRED as well. On the other hand, we could let inbound queue up backlog to merge post-migration and let those with approved bugs land directly. We could also press another tree into service for the holding tank, and have an APPROVAL_REQUIRED inbound. So long as the goal of "only approved patches this week, thanks" is satisfied, I yield to the vikings on the best approach, there.

J

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
@johnath

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Ehsan Akhgari
On Mon, Apr 16, 2012 at 1:20 PM, Johnathan Nightingale
<[hidden email]>wrote:

> On Apr 16, 2012, at 12:19 PM, Jonathan Kew wrote:
>
> >> We discussed a few other options on release-drivers (migrate to
> >> Aurora early, put mobile development on other branches, do nothing)
> >> but each seemed like a worse outcome to me than using the
> >> APPROVAL_REQUIRED hook we already have. We can get the flag added
> >> today, but first I want to know whether there are any deal-breaker
> >> concerns with this proposal.
> >
> > Could you clarify how you expect trees that regularly merge to m-c (in
> particular, mozilla-inbound) to operate during this period? Should we
> assume such merges will be suspended (although individual approved patches
> might be transplanted), or should inbound *also* be made APPROVAL_REQUIRED,
> or what?
>
>
> I'd be interested in thoughts, really. The approval required hook will
> bounce pushes without a= (whether on each changeset or just the topmost, I
> don't remember) so by default, I think mozilla-inbound would be de facto
> APPROVAL_REQUIRED as well. On the other hand, we could let inbound queue up
> backlog to merge post-migration and let those with approved bugs land
> directly. We could also press another tree into service for the holding
> tank, and have an APPROVAL_REQUIRED inbound. So long as the goal of "only
> approved patches this week, thanks" is satisfied, I yield to the vikings on
> the best approach, there.
>

We could temporarily maintain another version of inbound on the birch
branch which will be where people would land their a-minused patches, and
we can do daily merges from mozilla-central to birch to ensure proper
integration, and then we can merge birch to central once the migration
happens.  This will be more work for the merge vikings, but will make
things much simpler for the rest of us.  I volunteer to own birch if nobody
else wants to.

--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Jeff Muizelaar-4
In reply to this post by Johnathan Nightingale

On 2012-04-16, at 10:56 AM, Johnathan Nightingale wrote:

> Howdy folks,
>
> The new Fennec is getting close to beta quality. We're taking down the remaining beta blockers[1] and hope to push it in the next few weeks. As with major desktop releases in the pre-train days, we feel a lot of pressure to lock this one down and get it out the door. Part of this pressure is internal, because we are getting close and we can feel it and we don't want any surprises. Part of it is external because it's really much better than the XUL fennec currently in the market, and we want to get these improvements out to users.
>
> Fennec is based on Gecko 14, which is still on mozilla-central for another 9 days. I'd like to ask that we move mozilla-central to APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk of a late-landing change breaking Fennec. I'd propose that desktop-only changes get swift approval, and that we should have daily triage for all other requests to ensure we don't introduce too much drag.

What about Fennec changes? It would suck to introduce additional drag into getting Fennec done.

-Jeff
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Mike Connor-4
On 2012-04-16, at 4:03 PM, Jeff Muizelaar wrote:

>
> On 2012-04-16, at 10:56 AM, Johnathan Nightingale wrote:
>
>> Howdy folks,
>>
>> The new Fennec is getting close to beta quality. We're taking down the remaining beta blockers[1] and hope to push it in the next few weeks. As with major desktop releases in the pre-train days, we feel a lot of pressure to lock this one down and get it out the door. Part of this pressure is internal, because we are getting close and we can feel it and we don't want any surprises. Part of it is external because it's really much better than the XUL fennec currently in the market, and we want to get these improvements out to users.
>>
>> Fennec is based on Gecko 14, which is still on mozilla-central for another 9 days. I'd like to ask that we move mozilla-central to APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk of a late-landing change breaking Fennec. I'd propose that desktop-only changes get swift approval, and that we should have daily triage for all other requests to ensure we don't introduce too much drag.
>
> What about Fennec changes? It would suck to introduce additional drag into getting Fennec done.
One motivating factor here is that even within mobile-specific areas we're getting into an endgame, and we should be managing risk in all areas.  Just because something is mobile-specific doesn't mean the risk calculus is correct to grant blanket approval.

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Dave Townsend
In reply to this post by Johnathan Nightingale
On 04/16/12 13:03, Jeff Muizelaar wrote:

>
> On 2012-04-16, at 10:56 AM, Johnathan Nightingale wrote:
>
>> Howdy folks,
>>
>> The new Fennec is getting close to beta quality. We're taking down the remaining beta blockers[1] and hope to push it in the next few weeks. As with major desktop releases in the pre-train days, we feel a lot of pressure to lock this one down and get it out the door. Part of this pressure is internal, because we are getting close and we can feel it and we don't want any surprises. Part of it is external because it's really much better than the XUL fennec currently in the market, and we want to get these improvements out to users.
>>
>> Fennec is based on Gecko 14, which is still on mozilla-central for another 9 days. I'd like to ask that we move mozilla-central to APPROVAL_REQUIRED for the next 9 days so that we can reduce the risk of a late-landing change breaking Fennec. I'd propose that desktop-only changes get swift approval, and that we should have daily triage for all other requests to ensure we don't introduce too much drag.
>
> What about Fennec changes? It would suck to introduce additional drag into getting Fennec done.

I'm hoping that the Fennec changes would be the ones getting the most
attention in this process, since it is Fennec that we're trying to keep
from breaking.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Marco Bonardo-2
In reply to this post by Johnathan Nightingale
On 16/04/2012 19:30, Ehsan Akhgari wrote:
> We could temporarily maintain another version of inbound on the birch
> branch which will be where people would land their a-minused patches, and
> we can do daily merges from mozilla-central to birch to ensure proper
> integration, and then we can merge birch to central once the migration
> happens.

Honestly, don't understand all of this complication, can't we just let
people land on inbound and freeze m-c?
Inbound was created also to allow freezing m-c without blocking everyone
and this is exactly that case.
So I suggest we just freeze central, anyone can land on inbound, only
approved patches can land in central. Daily we merge FROM central TO
inbound, but we don't do the opposite merge till the freeze is over.

-m
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Ehsan Akhgari
On Tue, Apr 17, 2012 at 9:53 AM, Marco Bonardo <[hidden email]> wrote:

> On 16/04/2012 19:30, Ehsan Akhgari wrote:
>
>> We could temporarily maintain another version of inbound on the birch
>> branch which will be where people would land their a-minused patches, and
>> we can do daily merges from mozilla-central to birch to ensure proper
>> integration, and then we can merge birch to central once the migration
>> happens.
>>
>
> Honestly, don't understand all of this complication, can't we just let
> people land on inbound and freeze m-c?
> Inbound was created also to allow freezing m-c without blocking everyone
> and this is exactly that case.
> So I suggest we just freeze central, anyone can land on inbound, only
> approved patches can land in central. Daily we merge FROM central TO
> inbound, but we don't do the opposite merge till the freeze is over.
>

That _would_ work if people would not land on inbound with the expectation
that they will get merged to central.  Not everybody may be reading this
thread, which is why I suggested closing down inbound (so that pushes
without a= in the commit message fail) and use a third integration branch
for the non-approved patches.)

--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Marco Bonardo-2
In reply to this post by Marco Bonardo-2
On 17/04/2012 16:12, Ehsan Akhgari wrote:

> On Tue, Apr 17, 2012 at 9:53 AM, Marco Bonardo <[hidden email]> wrote:
>> Honestly, don't understand all of this complication, can't we just let
>> people land on inbound and freeze m-c?
>> Inbound was created also to allow freezing m-c without blocking everyone
>> and this is exactly that case.
>> So I suggest we just freeze central, anyone can land on inbound, only
>> approved patches can land in central. Daily we merge FROM central TO
>> inbound, but we don't do the opposite merge till the freeze is over.
>>
>
> That _would_ work if people would not land on inbound with the expectation
> that they will get merged to central.  Not everybody may be reading this
> thread, which is why I suggested closing down inbound (so that pushes
> without a= in the commit message fail) and use a third integration branch
> for the non-approved patches.)

What's the difference? if their patches will be merged to birch are not
we still breaking their expectation to be merged to central?
What bad things may happen then? I suppose someone will sneak into
developers and ask, or check the tree status and figure out the reason.
A blog post + tree status + #developers topic can cover most of the
notification needs.

Another fact is that some devs are not even using inbound to limit the
number of cloned branches around, your proposal is now also adding Birch
to the plot.
I just don't think we need all of this complication, and it may
complicate tracking (devs would have to start tracking what's on
inbound, what's on Birch and what's on central, rather than just pushed
VS merged).
We lived for years with a single branch, the world won't come to an end
for 9 days back to the old situation :)

-m
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Johnathan Nightingale
On Apr 17, 2012, at 10:21 AM, Marco Bonardo wrote:

> We lived for years with a single branch, the world won't come to an end for 9 days back to the old situation :)


I think Ehsan's recognizing that many devs prefer the inbound model because it means not watching the tree the same way one does landing directly on central. Having said that, I think we should:

- Mark mozilla-central and mozilla-inbound as APPROVAL_REQUIRED. Patches will bounce off those without a=, but for approved patches the workflow is unchanged.
- If you want to land unapproved stuff for future integration into FF15, Ehsan has offered to keep birch in a healthy state, but if that is annoying to you, then sit tight and land next week in the usual ways.

Akeybl has offered to manage the mechanics of getting the bug added and spinning up daily triage - I think we should make that happen today. Thanks for the discussion and the flexibility and the offers to help.

J

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
@johnath

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Marco Bonardo-2
In reply to this post by Marco Bonardo-2
On 17/04/2012 16:34, Johnathan Nightingale wrote:
> I think Ehsan's recognizing that many devs prefer the inbound model because it means not watching the tree the same way one does landing directly on central. Having said that, I think we should:

Right, I was trying to keep those niceties by having inbound stay open
and not forcing anyone to clone again another tree.
PErsonally I'm fine with any plan we take, just wanted to point out a
couple downsides of the Birch plan.

Cheers,
Marco
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Ehsan Akhgari
On Tue, Apr 17, 2012 at 10:38 AM, Marco Bonardo <[hidden email]> wrote:

> On 17/04/2012 16:34, Johnathan Nightingale wrote:
>
>> I think Ehsan's recognizing that many devs prefer the inbound model
>> because it means not watching the tree the same way one does landing
>> directly on central. Having said that, I think we should:
>>
>
> Right, I was trying to keep those niceties by having inbound stay open and
> not forcing anyone to clone again another tree.
> PErsonally I'm fine with any plan we take, just wanted to point out a
> couple downsides of the Birch plan.
>

As far as I can tell, the only downside is having to clone another
repository, and I hope people can live with that (otherwise as Johnathan
mentioned, they can hold off on their patches for a week).

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Boris Zbarsky
In reply to this post by Marco Bonardo-2
On 4/17/12 11:09 AM, Ehsan Akhgari wrote:
> As far as I can tell, the only downside is having to clone another
> repository

Which is a huge downside for some contributors, actually.

> and I hope people can live with that (otherwise as Johnathan
> mentioned, they can hold off on their patches for a week).

Which is increasing the set of things people have to remember; precisely
what inbound is supposed to avoid.

I think Marco's right: we should just freeze central.  If someone has
patches that _need_ to land for 14, they should be asking approval.
Worst-case after the aurora merge, once they realize they missed the
merge.  If the patch is important enough that it would get approved
anyway, it would get approved the day after merge too.

And that keeps several hundred people from having to spend a week
juggling patches that they could just land and move on.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Mike Hommey
In reply to this post by Ehsan Akhgari
On Tue, Apr 17, 2012 at 11:09:39AM -0400, Ehsan Akhgari wrote:

> On Tue, Apr 17, 2012 at 10:38 AM, Marco Bonardo <[hidden email]> wrote:
>
> > On 17/04/2012 16:34, Johnathan Nightingale wrote:
> >
> >> I think Ehsan's recognizing that many devs prefer the inbound model
> >> because it means not watching the tree the same way one does landing
> >> directly on central. Having said that, I think we should:
> >>
> >
> > Right, I was trying to keep those niceties by having inbound stay open and
> > not forcing anyone to clone again another tree.
> > PErsonally I'm fine with any plan we take, just wanted to point out a
> > couple downsides of the Birch plan.
> >
>
> As far as I can tell, the only downside is having to clone another
> repository.

If you know mercurial enough, you don't need to really clone another
repository. But it's very easy to mess up with such setups.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Chris Peterson-12
In reply to this post by Boris Zbarsky
On 4/17/12 9:04 AM, Boris Zbarsky wrote:
> I think Marco's right: we should just freeze central. If someone has
> patches that _need_ to land for 14, they should be asking approval.

Could we uplift central 14 to aurora now (one week early)? Uplifting is
an existing process that does not block anyone. aurora sounds like the
more-stable-than-central, approval-required branch people are looking for.

We would not need to uplift all the channels, though aurora 13 would be
in limbo between aurora and beta until next week's uplift. Is there a
precedent of uplifting one channel before others?


chris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Axel Hecht
On 17.04.12 19:18, Chris Peterson wrote:

> On 4/17/12 9:04 AM, Boris Zbarsky wrote:
>> I think Marco's right: we should just freeze central. If someone has
>> patches that _need_ to land for 14, they should be asking approval.
>
> Could we uplift central 14 to aurora now (one week early)? Uplifting is
> an existing process that does not block anyone. aurora sounds like the
> more-stable-than-central, approval-required branch people are looking for.
>
> We would not need to uplift all the channels, though aurora 13 would be
> in limbo between aurora and beta until next week's uplift. Is there a
> precedent of uplifting one channel before others?

Uplifting now would cut into the aurora phase of 13, in particular, the
localization of Desktop 13.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: mark mozilla-central APPROVAL_REQUIRED for the next week

Kevin Brosnan-2
In reply to this post by Chris Peterson-12
On Tuesday, April 17, 2012 10:18:55, Chris Peterson wrote:

> On 4/17/12 9:04 AM, Boris Zbarsky wrote:
>> I think Marco's right: we should just freeze central. If someone has
>> patches that _need_ to land for 14, they should be asking approval.
>
> Could we uplift central 14 to aurora now (one week early)? Uplifting
> is an existing process that does not block anyone. aurora sounds like
> the more-stable-than-central, approval-required branch people are
> looking for.
>
> We would not need to uplift all the channels, though aurora 13 would
> be in limbo between aurora and beta until next week's uplift. Is there
> a precedent of uplifting one channel before others?
>
>
> chris
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

This was one of the initial set of suggestions and dismissed due to
downstream partners among other reasons.

Kevin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12