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. I also wonder why you have a peculiar insistence that comm-central code > must not appear to any contributor, given the continued existence of "stuff > that Firefox doesn't care about" in mozilla-central, such as support for > tier-3 platforms (do we still have QT code in the tree) or xulrunner. FWIW, I personally think we should remove things things from the tree. The mere presence of code in a codebase has proven to be horribly > insufficient to guarantee that people care about maintaining it--history > has time and time and time again shown that any code that doesn't impact > Treeherder results *WILL* get broken. > That doesn't stop people from spending time fixing already-broken code, though, or from being discouraged from removing an unused API that is referenced from tier-3 code. bholley _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
