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

[Jan Hudec]

On Thu, Jul 01, 2004 at 22:59:17 +0100, Andrew Suffield wrote:
> On Thu, Jul 01, 2004 at 01:58:46PM -0700, Tom Lord wrote:
> >      One example is the very ad hoc way that we exchange
> >      patches, even when we're using arch for that exchange.
> >      It would currently be impossible (just because we're
> >      sloppy and inconsistent about patch submission) to 
> >      do something obvious and useful like set up a browser
> >      that can show all of the changes that are in the 
> >      Bug Goo queue.
> 
> And the only blocking prerequisite on this is:
> 
> >   1. We need a standard for how to submit changes.
> 
> I have most of the other pieces either in mind or on hand. My current
> low-level plan is to have something like
> address@hidden/tla-merges--merge-xx--0 be a
> copy of the merge. What I don't have is an method for submitters to
> describe how to construct that branch, or any really good ideas about
> how to do it. Everything is stuck until this is solved. Solutions need
> to consider what 'tla submit' (or whatever) is going to do, because it
> needs to generate these.

If I could add my 2c, it'd suggest a format. Since arch will be used for
creating that branch, the merge request must translate to arch commands.
It should not translate to arbitrary commands, but only specified set of
commands and only be able to specify some of their arguments.

There are 4 tla commands (at least I can't imagine any others) that can
be used for constructing the branch that should get parameters from the
merge request (6 actualy, I'll get to it). These 4 are:

    star-merge
    apply-delta
    replay
    apply-changeset

I think each of them is appropriate for some kind of contributions, so
Bug Goo should support all of them. Though I think the interface could
be unified a bit.

As far as calling them goes, an rfc2822 "pseudo-header" in a mail
message seems reasonable to me. It should be reasonably simple to send
and reasonably simple to parse.

So I would propose, that Bug Goo (or some slave script, that will get
distributed separately or even as part of arch later) could parse
following pseudo-headers in a merge request mail.

Star-Merge: <revision>
    This would star-merge given fully-qualified revision on the merge
    branch.

Apply: <revision> <revision>
    This would apply-delta of those two revisions on the merge branch.

Apply: <revision>
    This would replay given revision on the merge branch.

Apply: <name>
    If there is a mime attachment in the message with given filename, it
    would apply-changeset that attachment on the merge branch.
    The changeset should be assumed tarred and compression detected from
    mime. So:
    Content-Type: application/x-gzip
    would be considered to mean:
    Content-Type: application/x-tar
    Content-Encoding: x-gzip
    Because many MUAs don't detect what is gzipped.

The Apply variants could be named differently, if you consider it
cleaner, of course (then I think they should be Apply-Delta, Replay and
Apply-Changeset respectively).

Now I think that two more auxiliary pseudo-headers are needed. These
are:

Archive-Location: URI
    This might be necessary to introduce the archives that contain the
    changes to merge. Other discovery methods might be employed (like
    checking sourcecontrol), but an explicit one should exist.

Target: <tag>
    I suppose several predefined targets may exist. Eg. "stable" or
    "devo". Though I am not sure if it does not duplicate argument to
    MERGE itself for Bug Goo. Would still be easier for submit to
    generate, probably.

Except for Target header, multiple occurance of which does not make
sense, all the headers might occur more than once. The Target and
Archive-Location headers might be required before the Apply/Star-Merge
ones for ease of implementation.

The action headers should be processed one by one in order of
appearance. After merging each a commit should be done. This would make
simple method to split up large merge requests to smaller chunks that
can be reviewed separately.

Now I imagine submit command could behave similarly to what the debian
reportbug script does. It would make up the headers and then spawn
editor or MUA to finish the message to send.

It could be smart enough to guess, that if you used fork to create that
branch, you want to generate star-merge request. If you did not and
there are uncommited changes, you want an apply-changeset request (you
untar tla, fix two statements somewhere and submit) and otherwise should
probably either require arguments, or just spawn MUA with empty message
to appropriate recipient and let user write the headers.

> I think that this is the right way to approach the problem - given
> those branches, we can construct most anything else on top of it (like
> throw a browser at the category). It's always possible to construct
> the change directly from the merge request - but most of the time you
> just replay from the relevant branch.
> 
> -- 
>   .''`.  ** Debian GNU/Linux ** | Andrew Suffield
>  : :' :  http://www.debian.org/ |
>  `. `'                          |
>    `-             -><-          |



> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

signature.asc
Description: Digital signature