On Fri, Oct 23, 2015 at 8:57 AM, Mike Hommey <m...@glandium.org> wrote:
> Hi, > > This has been discussed in the past, to no avail. I would like to reopen > the discussion. > > Acknowledgment: this is heavily inspired from a list compiled by Joshua > Cranmer, but please consider this *also* coming from me, with my build > system peer hat on. > > What: > > Let's first summarize what this is about. This is about moving the > development of Seamonkey, Thunderbird, and Lightning in the same > repository as Firefox, by merging all their code and history from > comm-central into mozilla-central. > > Seamonkey and Thunderbird share a lot, so comm-central without > Seamonkey wouldn't make a significant difference. Lightning is, AIUI, both > standalone and an addon shipped with Thunderbird, so in practice, it > can be considered as being part of Thunderbird. > > Why: > > - The interaction between the build system in mozilla-central and the > build system in comm-central is complex, and has been a never stopping > cause of all kinds of problems sometimes blocking changes in the > mozilla-central build system, sometimes making them unnecessarily more > complex. > > - The interaction between both build systems and automation is complex, > and got even more twisted with mozharness now being in > mozilla-central, because of the chicken-and-egg problem it introduces, > making integration with mozharness hard. > > - Likewise with taskcluster. > > - Subsequently, with mozilla-central now relying on mozharness and soon > switching away from buildbot, the differences in setup with > comm-central keep increasing, and makes maintaining those builds a > large hurdle. > > - Historically, the contents of comm-central used to be in the same > repository as everything else, and the build system has never really > copped with the separation. Arguably, this was in the CVS days. > It's a testament to our build and release engineers that the cobbled > together result has held up for as long as it has, but it's really > not sustainable anymore. > > - mozilla-central and comm-central are as tied as top-level > mozilla-central and js/ are. Imagine what development would look like > if js/ was in a separate repository. > > - Relatedly, many codebase-wise changes (e.g. refactorings), or core API > changes tend to break comm-central. While it can be argued that it > shouldn't be platform engineers' burden to care about those, the fact > is that even if they do care, the complexity of testing those changes > on try or locally doesn't even slightly encourage them to actually do > the work. > > - TTBOMK, Thunderbird is Mozilla's second largest project in terms of > number of users, behind Firefox, and before Firefox for Android and > Firefox OS. Many of those users may legitimately want to contribute > to Thunderbird, and the bar to entry is made much higher by the > multi-repository setup and the extra complexity it entails. Mozilla is > actively making the bar to entry for Firefox/Firefox for > Android/Firefox OS contributions lower, at the expense of Thunderbird > contributors. This is a sad state of affairs. > +1 as someone who works on the build system, mach, and automation configs. comm-central is a giant thorn in my side and prevents me from moving faster. > > Why not, and counter-counter-arguments: > > - It would increase mozilla-central significantly. > Well, first, it's true, for some value of "significant". > comm-central is about 131M of .hg/ data, while is about 2309M as of > writing. That's a 5.7% increase in size of the repository. On the > other hand, 131M is less than the size mozilla-central grew in the > last 3 months. > On disk size isn't that important, as disk space is cheap. What is concerning is wire transfer size because that makes it harder for people on slow internet to clone. And, accordingly to https://hg.cdn.mozilla.net/, comm-central is only 71MB over the wire. We've already increased mozilla-central wire size by 150+ MB since ESR 38. Also, there are some changes in Mercurial 3.6 that will allow us to reduce the wire size by >100 MB. I don't think this extra size is worth worrying about. > > - It sets a bad precedent, other Gecko-based projects might want to > merge. > - mobile/ set the precedent half a decade ago. > - as mentioned above, historically, everything was in the same > repository, and the split can be argued to be the oddity here > - there are barely any Gecko-based projects left that are not in > comm-central. > I think the qualification for in-tree inclusion is what projects we run automation for. > > - It adds burden to developers, needing to support those projects > merged from comm-central. > Just look around in mozilla-central at all the optional things > that are not visible on treeherder and break regularly. The > situation wouldn't be different in that sense. But the people > that do care about those projects will have a better experience > supporting them. > IMO this is one of the two serious concerns. However, I /think/ it will only add an incremental burden. If nothing else, perhaps this will force us to better invest in tools that automatically handle refactorings. The other serious concern is impact to automation. Are we going to close trees for Thunderbird failures? Are we going to run Thunderbird jobs on every push? (Do we do this now?) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
