On 4/30/2013 2:46 AM, Gregory Szorc wrote: > 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? > I think the key point you're missing here is that the appeal of inbound is based on the fact that we have sheriffs willing to monitor it. Using project branches assumes that you can either coerce the sheriffs to monitor a bunch more trees, or project members using those branches will act as sheriffs. Neither of those seems particularly likely. RyanVM's proposal is fairly tightly scoped so that it doesn't add a lot of undue burden on sheriffs.
Given the discussion, I think this is probably the best short-term project to try. -Ted _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
