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

[Tom Lord]

    > 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 and to be
easily displayed by web browsers.   

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

For those other purposes, a simple and limited format is best.

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.


    > 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.

(But it'll be easier to script preparing such submissions than to 
cope, server-side and onward, with arbitrary merge requests.)

(And sure, raw unidiff and tarred-up mkpatch changesets work too,
that's fine.)


-t