[Gnu-arch-users] Changeset submissions for merge requests

[Andrew Suffield]

Support for formally capturing changeset submissions is now active. A
merge request is mapped by number to a branch, like this:
address@hidden/tla-merges--merge-49--0

Merge requests can and should contain the following pseudo-header
fields, which are used to construct the branch:

Archive-URI

        This gives the URI at which your archive can be found. It's
        only strictly necessary the first time you submit something
        from the given archive, after which it stays registered on the
        server. If you need to *change* the registered URI, you have
        to talk to me.

Base-Revision

        This gives the revision which your changes should be applied
        against. Anything accepted by tag will work; you can say
        'address@hidden/tla--devo' to grab whatever is the latest
        at that time. Make sure that your changes actually apply
        against the named revision, or they will be rejected.

Revision

        This is a comma-delimited list of revisions to be
        applied (or you can use multiple Revision fields, or mix the
        two; they'll be folded into a single list). It'll be fed to
        replay --list, so you have to list precisely the changesets to
        be applied - no ranges or following ancestry.


For merge requests which have already been submitted, use an [UPDATE]
tag, which accepts all these headers. Example:

 From: ...
 To: address@hidden
 Subject: [UPDATE: merge-15] Fix a couple of bugs

 Archive-URI: ...
 Revision: address@hidden/c--b--v--patch-n

 I just noticed my previous patch causes an anthrophagous bovine to
 viciously assault the user; here's a fix to make it heiferless.

This is also now the preferred way to add comments to an existing bug
or merge request while starting a new thread; if there is no
pseudo-header, then it'll just get appended to the summary. The
subject line will be passed to commit as the revision summary.

If you specify Base-Revision a second time, then a new tag is made
into the branch - in effect, all earlier changesets are
discarded. This is for use when you managed to mangle the submission
to the point where you can't fix it by adding another revision.


Supplying changesets in this manner is a prerequisite for the voting
system, which should be coming online in the next week or so. Your
merge requests are more likely to be dealt with promptly if filed in
this manner.

If you have outstanding merge requests, which have not already been
merged, you should file updates for them to attach the changesets
properly. Outstanding requests which *have* been merged should already
have been disposed of, but a number haven't - give me a list and I'll
push them out of the way.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature