> Is there sanity to this proposal or am I still crazy?
If we had a lot more project branches, wouldn't that increase the load
on infra dramatically, because we'd have less coalescing?
This is of course a solvable problem, but the fact that the problem
exists suggests to me that your proposal here should be considered
separately from RyanVM's tightly-scoped proposal here.
On Tue, Apr 30, 2013 at 2:46 AM, Gregory Szorc <g...@mozilla.com> wrote:
> On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote:
>> Specific goals:
>> -Offer an alternative branch for developers to push to during extended
>> inbound closures
>> -Avoid patch pile-up after inbound re-opens from a long closure
>>
>> Specific non-goals:
>> -Reducing infrastructure load
>> -Changing pushing strategies from the widely-accepted status quo (i.e.
>> multi-headed approach)
>> -Creating multiple integration branches that allow for simultaneous
>> pushing (i.e. inbound-b2g, inbound-gfx, etc)
>>
>> My proposal:
>> -Create an inbound2 branch identically configured to mozilla-inbound.
>> -Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED.
>> -In the event of a long tree closure, the last green changeset from
>> m-i will be merged to inbound2 and inbound2 will be opened for checkins.
>> ---It will be a judgment call for sheriffs as to how long of a closure
>> will suffice for opening inbound2.
>> -When the bustage on m-i is resolved and it is again passing tests,
>> inbound2 will be closed again.
>> -When all pending jobs on inbound2 are completed, it will be merged to
>> m-i.
>> -Except under extraordinary circumstances, all merges to
>> mozilla-central will continue to come from m-i ONLY.
>> -If bustage lands on inbound2, then both trees will be closed until
>> resolved. Tough. We apparently can't always have nice things.
>
> If you consider that every repository is essentially a clone of
> mozilla-central, what we have *now* is effectively equivalent to a
> single repository with multiple heads/branches/bookmarks. However, the
> different heads/branches/bookmarks differ in:
>
> * How much attention sheriffs give them.
> * The automation configuration (coalescing, priority, etc).
> * Policies around landing.
> * How developers use it.
>
> These are all knobs in our control.
>
> When we say "create an inbound2," we're essentially establishing a new
> head/branch/bookmark that behaves much like "inbound1" with a slightly
> different landing policy. If that's what we want to do, sure. I think
> it's better than a single, frequently closed inbound.
>
> Anyway, no matter how much I think about this proposal, I keep coming
> back to the question of "why don't we use project branches more?"
> Instead of everyone and her brother landing on inbound, what if more
> landings were performed on {fx-team, services-central, <wood-named
> twig>, etc}? I /think/ the worst that can happen is merge conflicts and
> bit rot. And, we can abate that through intelligent grouping of related
> commits in the same repository, frequent merges, and maybe even better
> communication (perhaps even automatically with tools that alert
> developers to potential conflicts - wouldn't it be cool if you updated a
> patch and Mercurial was like "o hai - Ehsan recently pushed a Try push
> that conflicts with your change: you two should talk.").
>
> As a counter-proposal, I propose that we start shifting landings to
> project branches/twigs. We should aim for a small and well-defined set
> of repositories (say 3 to 5) sharing similar automation configuration
> and sheriff love. By keeping the number small, it's easy to figure out
> where something should land and it's not too much of an extra burden on
> sheriffs. We can still keep inbound, but it should only be reserved for
> major, cross-repository landings with multi-module impact (e.g. build
> system changes), merges from the main landing repositories (unless we
> merge straight to central), and possibly as a backup in case one of the
> landing repositories is closed.
>
> We can test this today with very little effort: we figure out how to
> bucket commits, re-purpose existing repositories/twigs, and see what
> happens. If it works: great - we've just validated that distributed
> version control works for Firefox development (as opposed to the
> CVS/Subversion workflow we're currently using with inbound). If not, we
> can try variations and/or the inbound2 idea.
>
> Is there sanity to this proposal or am I still crazy?
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
