I would have rather done this in a private email, but some replied and said I wasn’t clear.
-> Do not merge comm-central into mozilla-central <- 1) I think merging comm-central is a bad idea as it will basically tax all gecko + firefox developers forever. 2) It isn’t clear that Thunderbird is a supported product anymore. MoCo certainly isn’t responsible for it. I don’t think MoFo does anything for it. 3) We’re spending $ and time in Release on this project. I would rather not have to do that given (2). 4) This sets a bad precedent. I don’t think we want every application built on top of gecko to be in mozilla-central. We don’t have all of the time and resources in the world. We have to be very deliberate about what we work on. And Thunderbird — as it is now — isn’t something MoCo is focusing on. Because of this, I really doubt anyone in moco Release is going to futz with it. Doug > On Nov 6, 2015, at 9:20 AM, Doug Turner <do...@mozilla.com> wrote: > > 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
