A merged comm-/mozilla-central repository is now available

Tony Mechelynck antoine.mechelynck at gmail.com
Thu Dec 24 16:44:47 UTC 2015


On Tue, Dec 22, 2015 at 10:00 AM, ishikawa <ishikawa at yk.rim.or.jp> wrote:
[…]
> I wonder how many of C-C patch contributors want to have a single gigantic
> repository instead of separate repositories.
[…]

Hard to tell.

One thing is certain: anyone working only with Firefox couldn't care
less about the code for Mail, LDAP, Suite, ChatZilla and DOM
Inspector. OTOH, people working on SeaMonkey need them all, people
working on Thunderbird need a subtantial part of them, and both kinds
of people need Gecko, Toolkit, NSS, NSPR, etc., let's say most or all
of what lives in mozilla-central or its branch avatars.

In the past (and, I think, in the present), the c-c client.py took
care of that by pulling and updating all six (six! or now five now
that Venkman is dead) repositories (at least when preparing to buils
SeaMonkey), in the proper order, and graft them all into a single
directory tree which could be used either for compiling or (e.g. with
the mq extension to Mercurial) to work on proposed patches. The result
is a single gigantic tree structure, which make treats as a recursive
and (hopefully) consistent unit (with Makefiles and config scripts at
several levels) while to Mercurial each of the handful of repos is
totally independant of all the others.

I have in the past contributed a few patches to SeaMonkey but I
wouldn't regard myself as a "developer": these patches were
elementary, mostly one-liner or few-liner portings from Firefox or
Thunderbird. I had no real difficulties with it, but all my changes
were in comm-central. If I had been working on Toolkit instead, and
more experienced, I might (considering that I'm not on MoCo's payroll
;-) ) taken care of the side-effects of my patches on not only Firefox
but also Thunderbird and SeaMonkey and provided patches, or rather
*sets* of patches, straddling mozilla-central and comm-central. I'm
saying sets of patches because not only patches to Toolkit, Browser,
Mail and Suite need to pass review with different reviewers, pushing
to momzilla-central and pushing to comm-central MUST be done
severally. I was always conscious of that, but I have seen young patch
contributors who tried to mix suite/ and mozilla/ in a single patch,
and of course it didn't pass review. Last I tried (but that was maybe
a year ago) this repository structure didn't pose insurmountable
problems, but OTOH I've seen the SeaMonkey RelEng team struggle to
publish releases and nightlies on a more or less regular schedule, and
Kairo saying in this very thread that (I paraphrase) that client.py
system was falling in pieces, and I wouldn't say that to them it's a
piece of cake. So who am I to stand against a simplification of
procedures, even at the cost of repository "gianthood"? I won't.

Now that we will be (collectively I mean: TB+SM) masters of the
repository (or repositories) used to build our beloved mailer and
suite, we could either put everything in a Single Mercurial repository
or take advantage of something I have seen mentioned time and again on
the Mercurial mailing list (mercurial at selenic.com IIRC) but haven't
studied, namely a Mercurial extension called "subrepository". I'm not
saying we necessarily should adopt it, just that we should be aware of
its existence. I think it would have both advantages (such as allowing
to pull smaller repositories, and thus, for instance, run a lesser
risk of network timeout in the case of a cloning) and inconvenients
(such as the necessity, I think, to make sure to have a consistent
repository set before going over to the compile phase, the way we did
with branch tags and client.py).

So in conclusion, I think there are several kinds of c-c "developers"
(in the wide sense of the word) who would prefer one repo rather than
five:
— old hands, who are aware of the complexity of the present system,
and feel bothered by the necessity of always keeping it in mind,
though they do;
— RelEng engineers, whose task would be enormously simplified,
especially on aurora, beta and release branches (where the changesets
to be pulled are not necessarily the head of the default branch for
every repository, especially, in the present situation, ChatZilla and
DOM Inspector);
— people trying their hand at "good first bugs", who would run the
less risk of coming afoul of the repository structure, the simpler it
would be.

Others might prefer separate repositories:
— the developers for cZ and DOMi, who would have to reserve disk space
for a full m-c + c-c + LDAP + cZ + DOMi clone, and not just their own
source. I'm not surprised that they seem to be still uncertain whether
they'll join the party (the feast I mean, not the pressure group).
— people who never "compile their own" but merely contribute patches
and maybe have them built by the Thunderbird try-servers in order to
test them.
— people with a slow Internet connection or a heavily busy CPU, who
would run less risk of connection timeouts when pulling a number of
successive new changesets and updating to the last of them if there
were less data to be pulled in each Mercurial run (considering that if
there is a timeout, Mercurial will throw to the dustbin anything
pulled so far).

People who, like I used to, contribute patches maybe a handful of
times a year, and are loath of building a c-c application anyway
because of the incredible RAM+swap total needed to link the libxul,
could probably do with either repository architecture.


Best regards,
Tony.


More information about the tb-planning mailing list