monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] GCC and Monotone


From: Zack Weinberg
Subject: Re: [Monotone-devel] GCC and Monotone
Date: Tue, 02 Dec 2003 00:09:17 -0800
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Tom Tromey <address@hidden> writes:

> I thought I'd send out a rough draft of my "How to use Monotone for
> GCC" white-paper.  It should be pretty straightforward for most
> Monotone folks.
>
> Please comment and critique.  Eventually I'd like to get this in good
> enough shape that it could be used to make the case for switching gcc
> to use monotone.

This is very interesting.  I've been following monotone development in
a casual sort of way, - haven't tried to use it myself yet - and I
like what I see.

I went and reread bits of that old thread and I found this interesting
tidbit by Joseph Myers:

| Patches by email (with distributed patch review by multiple people
| reading gcc-patches, including those who can't actually approve the
| patch) is the normal way GCC development works.  Presume that most
| contributors will not want to deal with security issues of making
| any local repository accessible to other machines, even if it's on a
| permanently connected machine and local firewalls or policy don't
| prevent this.

In particular, the "Presume that ..." bit concerns me.  Monotone's own
development seems to be done by all the key developers hosting their
own HTTP-accessible depots.  I can guarantee most GCC contributors
don't want to install apache or other web server just to continue
working.  (and some of them can't, due to local policies, enforced
by firewalls or not)

Now I'm sure there is a style of operation which avoids this; I just
don't know what it is.  It might be helpful if you sketched out the
way people would work with patches in the new system.  I've read the
monotone manual and I'm still a little confused -- most of the people
you're pitching this to, won't even have done that.

Another key bit from Joseph:

| For GCC there clearly needs to be some server that has the mainline
| of development we advertise on our web pages for users, from which
| release branches are made, which has some vague notions of the
| machine being securely maintained, having adequate bandwidth, having
| some backup procedure, having maintainers for the server keeping it
| up reliably, having a reasonable expectation that the development
| lines in there will still be available in 20 years' time when
| current developers have lost interest.

Again I'm sure this can be done with monotone I just don't know how;
in particular I don't know how one changes the "official top of trunk"
on the "official" depot.  Propagate commands?  Magic emails?

...

> The second type [of merge] is merging across institutional
> boundaries.  Various entities maintain their own forks of gcc --
> most Linux vendors, Apple, BSD projects, etc.  monotone will
> facilitate merges across these boundaries.
>
> At first it might seem like this is against the interests of the gcc
> community, which has always tried to have a single release.  However,
> these forks already exist, and lowering the cost of merging across
> these boundaries should reduce the divergence here.  Also, lowering
> merging costs will free up some small amount of time for gcc hacking
> (developers who do the merge will have more time to hack, since merges
> will be much simpler).

I'd just like to second that this is a desirable thing.  A nontrivial
amount of people's time here at CodeSourcery is eaten by figuring out
which local patches can go back to the official tree and when.

> I find patch review and approval to be a pain.  We've given many
> people write-after-approval access to gcc simply to reduce the burden
> of checking in patches.  In those cases where users don't have write
> access, there is usually some work involved in applying the patch (and
> dealing with patch formatting issues and the like), and occasionally a
> to-and-fro as the original submitter asks for the patch to be applied.
>
> With monotone this burden is substantially reduced.  Frequent
> contributors can simply post changes in packet form, which can easily
> be viewed (with a GUI or with a special mode in your mailer).
>
> When using monotone, a patch approval message is identical to a
> commit.  There is no separate step, no fiddling with patch bits
> (except for non-monotone-using users -- analogous to those who don't
> use cvs today).  A patch can be signed by any number of people without
> harm.  Patches can also be rejected using this same mechanism.

Here's where I'd really like more detail on how it works.  I don't see
the answers in the manual.  Someone sends in a patch via email - I
assume this is via "monotone post".  I want to approve it into the
official tree. What exactly do I do?

(It would be nice, incidentally, if someone would write some glue to
integrate monotone with popular text editors and mail clients)

Related question: who's going to write the bugzilla integration?
Daniel Berlin has done a herculean amount of work and I would hate to
add to it.  (There are a lot of cool features of bugzilla, most of
which we aren't using, that would integrate very nicely with cool
features of monotone.  Patch review tags, for instance.)

> For people or instititutions fetching the gcc repository for the first
> time, we can take several approaches.  First, they could download from
> a friendly nntp server.  Second, they could simply copy an existing
> database from a friend.  And, third, we could offer copies of the gcc
> database (perhaps with different amounts of history, from "trunk only,
> recent past" up to "everything") for download via BitTorrent.

Something you don't address is disk usage.  Do I have to have a
complete copy of the GCC revision history on my local disk, even if I
don't want to?  How big is a complete copy anyway?  (Assume ~100MB
is acceptable for a large number of people, ~1GB is not.)

> I recommend we use "org.gnu.gcc" as the name of the trunk.  Other
> existing branches will be automatically renamed based on that, e.g.,
> "org.gnu.gcc.gcc-3_3-branch".
>
> Future branches will have more natural names, e.g., "org.gnu.gcc.3_5".

Why not rename gcc-3_3-branch to org.gnu.gcc.3_3 ?

zw




reply via email to

[Prev in Thread] Current Thread [Next in Thread]