Re: [Gnu-arch-users] Arch Roadmap Draft (the anticipated part 3)

[Jan Hudec]

On Wed, Jul 07, 2004 at 03:14:39 +0100, Andrew Suffield wrote:
> On Tue, Jul 06, 2004 at 07:11:39PM -0700, Tom Lord wrote:
> >     > From: address@hidden (James Blackwell)
> > 
> >     > I suggest the following format for a merge request: 
> > 
> >     > archive-location: (optional) 
> > http://bitmovers.com/archives/subvert-thyself
> >     > archive-name: address@hidden
> >     > contact: (optional) address@hidden
> >     > merge-patches: patch-10, patch-15..patch-20
> > 
> > I don't think so.   I think it makes more sense to require people to
> > make branches for submissions so that the merge technique is always
> > either replay of all patches on a branch or star merge or something
> > like that.
> > 
> > Those kind of cherry-picking merge requests centralize the labor
> > requirements to sort them out -- that won't scale.
> > 
> > Requiring submitters to make a branch for each request (roughly
> > speaking) distributes the labor -- that will scale.
> 
> Remember that merge requests are intended to be folded into a
> specifically named branch automatically by the bug tracker, such that
> they can just be replayed; this gives submissions a certain amount of
> flexibility - we can (and should) handle submissions as raw
> unidiff. Still, it has to be fully automated on both ends.

What about pseudo-headers that map relatively directly to tla commands?
Something like:

archive-location: (optional, perhaps more than once) URI

And then:

replay: revision
replay-reverse: revision
apply-delta: revision-1 revision-2
star-merge: version
apply-changeset: name
patch: name

Any number of any of these. Bug Goo would make a branch for the
merge-request and then carry out each of the commands, in order
specified. The apply-changeset would require attachment (of given name)
as gzipped and tarred arch changeset and patch would require attachment
(of given name) with unified diff.

After each command, it would commit the merge branch, so individual
parts would be easy to review separately. The commit log should probably
include what was merged and last commit caused by a single message could
include that message.

It should be possible that follow-ups contain more commands and these
would be carried out on the merge branch too. So if some polishing or
conflict resolution or some such is requires, it can be done by posting
follow-ups to that merge request.

> If nothing solid comes along soon, I'll make up something that sucks
> so badly everybody wants to rewrite it, and use that. It's probably
> going to be blocking the vote/queue stuff by next week.

I hope my suggestion does nto suck too much and is simple to
implement.

Then I think it will be even easy to extend to trusted and untrusted
merges. I imagine it along the lines of: If a commit should be done on
the merge branch AND the message causing it and the archive from which
merge is done are signed with a trusted signature, make test would be
run and it's results included in Bug Goo's replay. If not, the commit
would be marked as "UNTESTED" (presumably in it's summary).

When an 'untrusted' merge is recorded, someone with a trusted key could
send special command (say "commit"), that would only run make test and
commit with empty changes and log containing results of the test. It
would be only allowed in message with trused signature.

For this purpose, Bug Goo should probably have a key to sign the merge
branch with and it would be considered trused (so signed request to eg.
rever part of a merge is trusted).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature