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

[Andrew Suffield]

On Wed, Jul 07, 2004 at 03:12:41PM -0700, Tom Lord wrote:
> 
>     > From: Andrew Suffield <address@hidden>
> 
>     > 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.
> 
> But merge requests are intended for more than just that.  For example,
> they are also intended to be cherry-picked by other forks

replay from the constructed branch.

> and to be
> easily displayed by web browsers.   

delta from base-0 to tip.

> In our voting system, they're also intended to be revisable as when
> the maintainers vote "return" rather than "reject".

commit to the branch.

All else aside, I want to get the working copy of the change stored in
the same place as the bug tree, so that it doesn't go missing later
when the queue wants it. That leads me to express everything in terms
of a constructed branch in that archive, since it's more convinient
that way.

> In a large sense, this is just a client-side/server-side issue.
> 
> Let's suppose you have a little language for describing nearly
> arbitrary merges.   There's no reason not to process that further
> _before_ it hits the server.   The client-side can do the work of
> turning the free-form merge into a replayable changeset, then submit
> that replayable changeset.

That still holds, though.

>     > 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.
> 
> How about just:
> 
>       submission-in: $archive/$category--$branch--$version
> 
> for merge requests in the form of a submission branch (gack, I suppose
> we'll have to enable `commit --base'):
> 
> That'll be sure to piss everyone off at first.

Not quite enough, there's no obvious "update this merge request"
operation. I'm currently thinking of something like this:

A list of revisions, which can be appended to by later mails. The
first one is tagged, and the rest are fed to replay --list and
committed.

Where:

 - you can have an inline changeset (diff/mkpatch) instead of a revision
 - if the first revision is not present, it is immediately replaced
   with the head of [tla mainline] at the time the mail is received

That should be able to express anything while being horrible to
express most things. It's also possible to "fix" client-side.

The form you described is then a pair of revisions - base-0 and tip
from the submission branch.

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

signature.asc
Description: Digital signature