Re: [Monotone-devel] Re: GCC and Monotone

[Zack Weinberg]

> officialness isn't something you get to decide, absolutely, for the
> clients. you can of course publish "official" approval certs, signed
> by a key you advertize on www.gnu.org, but clients might decide to
> avoid such versions until they have certs from 3rd party testers and
> reviewers, too. monotone's designed to decentralize authority.

I realize this, but please understand that it's going to be much
easier for us GCC folks (or any large project for that matter) to
migrate to monotone if we don't have to change our development process
drastically at the same time.  Which isn't to say that we mightn't
like to try changing the process, just that we don't want to do it at
the same time.

That being so, the current development process for GCC revolves around
a small group of people who have authority to approve patches to
different components; who they are and which components is determined
by the steering committee.  I think this can be modeled by publishing
a list of public keys whose approval certs are to be taken seriously.
The issue is complicated by the "obvious fix" rule which says people
are allowed to check in sufficiently obvious fixes with no approval.
("Sufficiently obvious" being a fuzzy thing, of course, but it hasn't
been a problem in the past, although I occasionally want to yell at a
certain individual who constantly applies spelling/formatting tweaks
and thereby confuses "cvs annotate"... anyway.)  I don't know how to
do that part.

Another issue is merges. Tom addressed this briefly in his original
message, but let me spin it out a bit.  Suppose we set up a monotone
depot on gcc.gnu.org which accepts patch packets from anyone - no harm
done, because no one has to pay attention, right?  (Ignore denial-of-
service attacks for now.)  Now each patch is going to be relative to
whatever ancestor revision the patch's author was using.  By the time
someone gets around to approving it, things on HEAD may be very
different; we need to have a range of options available when issuing
that approval cert.  The basic action, I think, is "Approve this,
generate an automatic merge packet against HEAD, then let me look at
the result."  I then get to say "yes, good merge" or "no, let me fix
that" or "no, tell the original author to resolve the conflicts."  The
latter two leave the botched merge as tip of an evanescent branch, so
the work is not lost.  Does that make sense?

zw