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
