On 10/23/2015 10:22 AM, 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).
Why are we still arguing over this? It seems like BDS is fine with
merging it back in, as long as some reasonable objections are resolved
first.
With respect to the first one, I would personally like to further
request that a non-default, relatively easily findable, view be
available that *does* include non-Firefox code. I often search dxr for
callers of a function where I *want* to see as many users as possible. I
have no intention of "fixing" them, I just want to see them. It might be
because I'm answering a question along the lines of "does anyone ever
use it like this? Or have they in the past?" Or maybe I'm just searching
for example code. Or maybe I'm implementing something for my static
analysis and want to see whether it's worth handling a particular edge
case. "If they did it once, they might try to do it again."
For my personal usage patterns, it is more common that I'd want to see
results from m-c, c-c, external embedders, amo, and code from any other
random clueless idiot on the internet. I would prefer to have a default
view that showed anything from anywhere, with all past revisions
included, but to have every result clearly denote whether it's from the
current Firefox code (and have it sort those results to the top.) That
"past revisions" part would clearly incur some performance
considerations, but nothing that a dram or two of unicorn blood couldn't
dispel away.
For the second one, it feels like a bit of a scary amount of
complication in order to avoid seeing distracting code during a typical
grep, but it also feels like a good pragmatic way to minimize the
distraction caused by c-c's presence in the repo.
I can see that this might not be a satisfactory outcome to someone who
just wants to pull the trigger and merge it all in so they can get
cracking on build system improvements, without waiting on these annoying
tooling considerations. But if so, why aren't the continued arguments
focused on addressing BDS's (semi-)requirements? [note that gps *did*
respond to the sparse checkout portion; is the current state of that
support satisfactory? That's the blocking question here.]
Perhaps the concern is that it's foolish to merge it in now if the
direction of c-c development is going to end up needing it split out
eventually anyway? I doubt that's near enough at hand to matter,
personally, and splitting it back out doesn't seem hard.
- 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).
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.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
