On Fri, Oct 23, 2015 at 11:45 AM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> On Fri, Oct 23, 2015 at 11:17 AM, Joshua Cranmer 🐧 <pidgeo...@gmail.com> > wrote: > > Except that to demand contributors don't care about comm-central would be > > to demand of your employees that they should be jerks to the wider > > open-source community. Merging comm-central into mozilla-central, with > the > > exception of the time spent doing the actual merge work, would reduce the > > amount of time that core contributors would have to spend worrying about > > comm-central in the short and medium-terms for sure. > > > > I think framing it in terms of being "jerks to the wider open source > community" kind of begs the question of the tradeoff that's always at stake > here. It depends which parts of the community you're talking about. > > Having c-c code visible in m-c increases the chance that a developer will > take TB into account when making changes to FF. This might come in the form > of including it in a refactoring/cleanup (and spending extra time doing > so), or in discouraging a refactoring/cleanup of machinery that TB depends > on. > > We decided some time ago that we want to encourage those refactorings by > making them (a) more feasible and (b) take less time. The increase in > FF-focused refactorings and time-saving for FF-focused developers has an > outsize negative impact on TB and its developers. However, if FF has > outsize importance compared to TB, this tradeoff starts the make sense. > > Mozilla makes very few "demands" of contributors. However, high-level > decisions like repository configurations can tilt the ergonomics toward or > away from Mozilla's priorities, which is why they're important. > > It may well be that having c-c code in m-c decreases friction overall, > since it saves time for the people that know they're allowed to break TB > but choose to help it anyway. However, the cost of redirected work for > contributors that _don't_ know they're allowed to break TB is real. That is > the tradeoff that needs to be weighed IMO. What Bobby said here seems very important. In the cost/benefit analysis, the impact on Firefox needs to be weighted very heavily. In particular, breaking TB should not cause failures either on try or on commit, and changes to pieces of Gecko should not be held up on their impact on TB. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
