Re: [Monotone-devel] Approval revisited...

[Daniel Carosone]

On Fri, Feb 10, 2006 at 10:39:02PM +0100, Richard Levitte - VMS Whacker wrote:
> Yeah, the only problem, as far as I see it, is that approve takes
> --branch, so for example, I could very easily say something like:
> 
> monotone approve --branch=net.venge.monotone.approved.linux \
>       6e87084a87413eed2c31100054ff8d5045f0be4d
> 
> If that gets repeated a few, do you know what kind of graph that
> branch (which I invented on the spot) would have?  

There's nothing whatsoever intrinsically wrong with a disconnected
branch, so long as the users of that branch have appropriate
expectations.  Take a look a the BranchAnalogy page on the wiki for
some more discussion, if you haven't already; that's mostly intended
to explain the concept to new users, but there are some examples in
the discussion that are pertinent, iirc.

Here's a concrete hypothetical use case: in some slightly
alternate/future monotone, when we have the ability to grant netsync
write permissions by branch, we open up the public server and allow
anyone to push new revisions into a branch nvm.patch-submissions.  The
appropriate revid, or a suitable selector for it, then gets put into
bug trackers or sent to the mailing list, rather than the whole patch,
which might be large.

This branch will, typically, contain a whole pile of heads, many of
them clustered around the revisions tagged for releases, and some
others from users who follow mainline scattered in between.

Some of the patches will be good.  A monotone developer with suitable
rights/trusts reviews one of these patches, and finds it good. They
"monotone approve" that rev onto net.venge.monotone and "monotone
merge" to pull the patch back in to a new head on the mainline.

Furthermore, suppose several people submit slightly different patches
for the same issue.  Those revs can be explicit_merged, still in the
submissions branch, before the discrepancies are resolved and an
integrated patch proposal is approved onto mainline.  If this becomes
a significant amount of work, it will presumably be continued in a new
development branch for the purpose.

> I think approve should at least warn if the given branch doesn't match
> one of the branch certs already attached to the revision.

Well, maybe warn, but I see two primary uses for 'approve':

 - attest that code in some state (branch) is also appropriate for
   some other state (perhaps a release branch, or mainline), perhaps
   after code review.

 - reinforce an assertion already made, by adding another cert by a
   different signer, perhaps one more widely trusted (or perhaps for
   users in some branches that want multiple signers?)

My issue isn't really with "approve" at all: it's with the way that
"disapprove" does something entirely different.  I understand why, but
at the very least the name is wrong.

--
Dan.

pgpwFjapFEHRt.pgp
Description: PGP signature