Re: [Monotone-devel] GCC and Monotone

[Tom Tromey]

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

I wrote up some user scenarios for the next revision of the
document.  I've appended this part.

There are a couple FIXME notes where the ideal and the reality don't
quite meet yet.

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

I think we still need a little support from monotone.  There's still a
few important features like this that need implementing before we
could seriously consider monotone for gcc...

Zack> Related question: who's going to write the bugzilla integration?

I added this to the document as a potential problem.  I also mentioned
the potential problem of obvious patches, thanks for pointing that
out.  For the time being these are just placeholders with no text.

Zack> Something you don't address is disk usage.

There was a small section on this, but I've expanded it.

Tom


User Scenarios


New GCC hacker

You just got hired by Wonder Bread, Inc. and now you have to hack on
gcc.  How do you start?  You've already got monotone and all the other
usual Linux tools.

You visit gcc.gnu.org and it gives you various choices.  You can get
the full gcc history, which is nearly 1G.  But for the time being
you're only working on the trunk, so you choose the more
modestly-sized database that includes just a year's worth of history
on the trunk.  After all, you can always fetch more bits when you need
to.

This database is small enough that it is just served directly by the
gcc web server.  Larger databases are available via rsync (for special
folks) or bittorrent.

Finally, you configure monotone to work well with the GCC project.
This means setting the default "post" target to point to the
gcc-patches mailing list.  The standard public keys to trust are
already in the database image you downloaded, so there's no extra work
there.

There may be some other minor configuration.  For instance, you might
install an automatic ChangeLog merger, so that ChangeLog conflicts are
handled according to GCC rules.


Moving To A Branch

If you want to start working on a branch, where do the bits come from?
gcc.gnu.org will make packet archives available for download (larger
ones, again, via bittorrent).

So, the simplest approach is to just download a bunch of packets and
feed them into your database.

I would expect GCC-related companies to simply keep their own copy of
the master database, updated automatically, to provide a convenient
local packet repository.  I'd also imagine that many of the core GCC
developers will simply keep everything, as a convenience to
themselves.


Patch Submission

You've written a patch on the trunk and tested it.  Now you want to
submit it.  Just "monotone commit" and then "monotone post".  You're
done.

[ FIXME: one obvious problem here is that you'd like to send a
rationale with the patch.  Perhaps that should be an additional cert
of some kind?  How else will post know to send it?  Likewise, how
would you set the Subject line? ]


Patch Review

Another GCC contributor sends a patch and now you must review it.
Instead of the usual "cvs diff", he has simply used "monotone post" to
send his patch.

To the naked eye, the patch looks like garbage.  However, your mailer
has a button that redisplays the patch in patch format.  If you
approve of the patch, click the approve button.  This will issue an
"approve" cert.  At that point, the patch has been committed -- you
are done.

If you don't like the patch, issue a "disapprove" cert.

[ FIXME: another problem is that you have to process some mail twice.
I suppose you could have procmail send all packets to monotone, and
then also put them in your mailbox. ]


What Really Happens

The GCC project will have a master key.  Anything signed by this key
will be considered part of "GCC".  Running on gcc.gnu.org will be a
signing robot.  This robot will have a list of keys for all GCC
maintainers.  Any time a GCC maintainer approves something, the robot
will issue a new approve cert with the master key.

Adding a new maintainer is as easy as adding his private key to the
robot's list.

If desirable, the robot can enforce access controls.  For instance, it
would only auto-accept a change from a maintainer if that change
touches only files for which he has approval permission.  I don't
think GCC really needs to do this, but it is an option.


Commit Notification

Commit notification isn't a separate event, as it is with cvs.
Instead we just use the same mechanisms as we do for patch review.