Thanks a lot for thinking along here from the RelEng side of things! ----- Original Message ----- > From: "Alex Keybl" <ake...@mozilla.com> > To: "Bas Schouten" <bschou...@mozilla.com> > Cc: "dev-platform" <dev-platform@lists.mozilla.org> > Sent: Wednesday, March 27, 2013 11:25:14 PM > Subject: Re: Moz2D Repository Creation > > > Can you clarify the main motivation behind using a subrepo over a > Tier 1 dev branch like m-i or services-central? Mimicking what we > already do elsewhere would have less process/infra change overhead, > and my intuition tells me that per-checkin builds/tests could be > configured specifically for that repo. Perhaps we should be focusing > mostly on your point about " Improv[ing] sharing between > Servo/Gecko" though.
The main motivations would be: - Reduced tree size (for clone/pull/update/etc.) - Easier bisection within the specific Moz2D code. - Cleaner merging system (i.e. rather than merging, it would just be a revision tag update in m-c) > > > Assuming we move forward with a subrepo, a few thoughts: > > > * Whatever the branching model becomes, it sounds like it'll end up > being around merges. Just let us know what you'd like us to do at > m-c->m-a and upon subsequent merges. No problem there. Nothing should change for that, m-c -> m-a would just take the currently tagged revision along with it, and that would remain the revision used. For upstreaming patches the process gets a tiny bit different, see also your point below this one. I've added some of my own thoughts to the wiki page. > * We'll need to decide how to handle approvals - whether to gate at > landing to a branched subrepo, or updating the changeset in the main > repo. Just requires some discussion. > * Somebody (engineer, sheriff) would need to make sure that after > landing to a subrepo branch, a version of Firefox is marked as fixed > once it the changeset starts being referenced from the main repo. Yeah, this is an interesting point. The question is if it's defined fixed by being fixed on Moz2D or in Firefox, probably the latter is best. > > > As for impact to QA and investigations, I agree that the change > should be fairly minimal. Since we'd still like the help of > contributors and QA in bisecting a day's worth of Moz2D changes, new > documentation may be necessary. Indeed, a day (or a week) worth of Moz2D changes will be a lot easier to bisect though! :-) And could even be done within m-c where you'd for example only have to rebuild gfx/2d and layout/media, as long as your bisection doesn't include API changes. This would be one of the advantages of the separation listed above. > > > > -Alex Bas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
