On 2013-05-05 1:20 PM, Gregory Szorc wrote:
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code. Not everyone's project has enough manpower to get
that level of testing on a project branch before their stuff gets merged
to central/inbound. I personally cannot imagine doing my development in
a project branch silo and deprive myself of the huge advantage that this
kind of testing brings about.
That all depends on how one uses a "project branch".
If you use a project branch as a traditional staging area for work
that is large/complex and merge it infrequently, then yes. Those are
absolutely real problems.
But if you use a project branch as just a frequently-merged
integration branch, then I don't see these things as being problems. I
think that's what gps is proposing -- not the old-school usage of
project branches (maybe we need a new term?). Such branches would be
almost exactly the same thing as mozilla-inbound, and we don't worry
about those problems on inbound. We did exactly this in the past with
JS and Services (and to a lesser extent with fx-team)... We'd just
call them inbound-js and inbound-services now.
Frequently-merged integration branches are exactly what I'm proposing.
Naming is hard.
What would be the benefit of that compared to Ryan's proposal? The
downsides are clear: more branches to be sheriffed, more merge pain, and
worse usage of our infra capacity...
[AIUI, those teams stopped because inbound was working so well -- why
spend time running your own branch when m-i is just as good and
requires no effort? The twist now is that m-i is a victim of it's own
success, and so we should think about making the costs more directly
visible to project teams.]
I actually started reusing services-central as an inbound-like branch
because I was so frustrated dealing with inbound closures. It's merged
by not-the-sheriffs, does not get the normal starring love (I don't mind
starring my own pushes), and is merged less often. But, it works for our
needs.
I think Ryan's proposal addresses the inbound closure problem. Do you
see more problems that need to be addressed by using s-c as an
integration branch? I doubt that it is a scalable approach to ask every
team to maintain their own branches this way.
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
