It’s not a simple thing to just merge the code bases. It’s going to cause a bunch of work in Release which we’re just not signed up for. In our planning for 2016, I will add this to what we’d like to do — but no promises as there are lots of high priority things we need to get done.
Doug > On Nov 5, 2015, at 6:58 PM, Joshua Cranmer 🐧 <pidgeo...@gmail.com> wrote: > > This thread has quieted down for a while, but I don't want to let it die out > without a clear consensus being reached. > > What I want to know is whether or not there is sufficient consensus for the > merge to happen that I can start planning with release engineering and > automation on getting merged comm-central builds working, with an eye to > actually committing the merge in Q4 or Q1 (the master bug for this work will > be bug 787208). > > On 10/23/2015 2:57 AM, Mike Hommey 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. >> >> 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. >> >> - 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. >> >> - 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. >> >> Considering all the above, are there still objections to this >> happening, and can we finally allow Joshua to go ahead with his merge >> plan? (CCing bsmedberg, who, iirc, had Brendan's delegation to have the >> final word on this) >> >> Cheers, >> >> Mike > > > -- > Joshua Cranmer > Thunderbird and DXR developer > Source code archæologist > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
