On 10/23/2015 12:22 PM, 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).
It's a relatively easy matter to fix the first; the second is harder to
do for all contributors. I've been told it's a coming feature, but I've
been told this for a while.
I also wonder why you have a peculiar insistence that comm-central code
must not appear to any contributor, given the continued existence of
"stuff that Firefox doesn't care about" in mozilla-central, such as
support for tier-3 platforms (do we still have QT code in the tree) or
xulrunner. The mere presence of code in a codebase has proven to be
horribly insufficient to guarantee that people care about maintaining
it--history has time and time and time again shown that any code that
doesn't impact Treeherder results *WILL* get broken. (Easiest case in
point: try building without unified files.)
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).
And as Firefox development moves faster toward things such as stopping
supporting XUL addons, removing support for heavyweight themes, and
even cutting XUL altogether, we should all expect the impedance
mismatch to become worse. We are not only saying that you don't have
to fix comm-central apps: we're also saying that we don't *want* core
contributors to spend time on comm-central.
Except that to demand contributors don't care about comm-central would
be to demand of your employees that they should be jerks to the wider
open-source community. Merging comm-central into mozilla-central, with
the exception of the time spent doing the actual merge work, would
reduce the amount of time that core contributors would have to spend
worrying about comm-central in the short and medium-terms for sure.
From my perspective, your insistence on the bar to entry for Firefox
development (or, rather, explicitly deprioritizing Thunderbird and
Seamonkey) seems like a weak ad-hoc justification. How can you justify
letting core contributors take the time to review patches for systems
that Mozilla will never officially support--mingw, OpenBSD, iOS--while
saying that they shouldn't be taking the time to review patches for
systems that Mozilla officially supports?
--
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
