On Friday, October 23, 2015 at 3:58:07 AM UTC-4, 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
To be explicit, I am on the SeaMonkey Council (drivers), and am an employee of MoCo. >From the code complexity standpoint Mozilla Releng code would also be greatly >benefitted by the merge. Making our day-to-day easier and less cumbersome. >Though we don't deal directly with thunderbird, the ability to remove any/all >of the complexity which does would be a boon to productivity. Also we too have the "thunderbird is lower priority than everything else" mandate, to which I abide. That said, I also will heartily proclaim that I will do the releng work required by this merge (possibly including the dead-code-removal itself) in my own volunteer time. Which would allow us [decision makers] to ignore one of the few MoCo-employee-needed assumptions I've read in this thread (that is the assumption that releng needs to do changes to cope). ~Justin Wood (Callek) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
