Thanks for clarifying. Based on this, it seems like another way to solve this would be to simply stop worrying about breaking comm-central. Wouldn't that be even easier?
-Ekr On Fri, Oct 23, 2015 at 3:38 PM, Gregory Szorc <g...@mozilla.com> wrote: > On Fri, Oct 23, 2015 at 11:13 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Fri, Oct 23, 2015 at 3:11 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >>> On Fri, Oct 23, 2015 at 10:08 PM, Mike Hommey <m...@glandium.org> wrote: >>> >>> > On Fri, Oct 23, 2015 at 01:22:35PM -0400, Benjamin Smedberg wrote: >>> > > I support going back to a giant monolithic repository if we can >>> cleanly >>> > > delineate the code for various projects. >>> > > >>> > > We know that the searchability and readability of our code is a major >>> > > barrier to some kinds of participation. We should continue to >>> optimize >>> > > ourselves around that workflow. >>> > > >>> > > Does this proposal come with a plan to check out subsets of the >>> code? In >>> > > particular, I want to express the following as something inbetween >>> > "serious >>> > > concerns" and "requirements": >>> > > >>> > > * The default view of dxr.mozilla.org should not include >>> non-Firefox >>> > code >>> > > * The default checkout should not include non-Firefox code. (Note: >>> > > this is about the working tree: I don't think the space in the .hg >>> > > directory matters enough to worry about). >>> > > >>> > > >- 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. >>> > > >>> > > I'm sorry that it makes you sad, but Mozilla has explicitly decided >>> to >>> > > prioritize the bar to entry for Firefox development, and the speed of >>> > > development of Firefox, at the expense of Thunderbird (and >>> seamonkey). >>> > >>> > What's even more sad is that it's at the expense of Thunderbird (and >>> > SeaMonkey) *and* at the expense of Firefox build system changes. >>> >>> >>> I want to reiterate my original response and what Mike said in the >>> original >>> post. >>> >>> We'll be investing pretty heavily in the Firefox build system in 2016. I >>> cannot stress enough the pain comm-central's existence as a separate >>> repository gives us when trying to make build system, mach, and >>> automation >>> changes. It slows us down and makes our lives (and code!) more painful >>> than >>> they could be. >>> >> >> Can you explain why this is? Is it that the Firefox build system does not >> build the artifacts you would need to then build TB or is it that you need >> to somehow figure out how to make TB build alongside Firefox? >> > > comm-central's build system and tools are bolted on extensions to > mozilla-central's corresponding tools, which aren't really meant to be > extended in that way. mozilla-central's build system and tools like mach > have to make special considerations for running inside comm-central. The > relationships are hacky, not very well defined, don't have much visibility, > hard to debug, and are prone to breakage. The extra code complexity to > support running things from a separate repository (which means things like > teaching tools about the existence of multiple source directories) really > weighs us down. I've lost several days to "because comm-central" issues. > > As a concrete example that's come up in the past few weeks, we can't > easily make wanted changes to jar.mn files or packaging of add-ons/XPIs > because it means developing, testing, and coordinating landing of changes > across mozilla-central and comm-central. It's much easier to let > sub-optimal patterns linger in mozilla-central because the overhead of > developing a parallel set of changes for comm-central is too high. I dare > say the knowledge of impending dread from having to deal with comm-central > fallout has discouraged me from making major build system and tooling > changes. This situation passively hurts everyone. > > >> >>> Continued existence of comm-central as a separate repository will slow >>> down >>> build system, tools, and automation progress. The developer productivity >>> survey results say that Mozilla staff overwhelmingly want these things to >>> be much better. A vote against this proposal is a vote against making the >>> jobs of "toolers" easier and a vote delaying the progress of improvements >>> to developer workflows, infrastructure, productivity, and happiness. >>> >>> As a "tooler" who wants to make your lives better, I emphatically support >>> merging comm-central into mozilla-central. >>> _______________________________________________ >>> 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
