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
