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.
[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.]
Justin
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
