Re: [Gnu-arch-users] tla-pqm 0.2

[Tom Lord]

    > From: Colin Walters <address@hidden>
    > Date: Thu, 16 Oct 2003 20:44:07 -0400

    > So, I have been thinking a bit about the confluence between tla-pqm,
    > Tom's merge tracker, and a "smart server".

    > Certainly, I think tla-pqm could also help with merge tracking.

I strongly agree.   

    > For example, a tla command such as "submit-merge" would help.  It would
    > do essentially what is listed in the manual:
    > (echo "From: $(tla my-id)"; echo "Subject: $1"; echo; echo star-merge
    > "$(tla tree-version)" "$2") > /usr/src/tla-pqm/patch.$(date +%s)
    > Or the user could specify to use email.  It also would be good to have a
    > way to specify a default archive/revision to send merge requests to; say
    > {arch}/=3Dupstream or something.  This would list both the queue location
    > or submit email address, as well as the archive name, so all the user
    > needs to say is "tla submit-merge -s 'fixed some bugs'".

    > One other thing I have been thinking about that tla-pqm can do is "meta
    > commits".  What you'd like to be able to do is say something like this:

    > star-merge address@hidden/hackerlab--mainline--0 hackerlab
    > star-merge address@hidden/tla--mainline--0 tla

    > ...and require that if one command succeeds, all commands succeed.  This
    > would be nice for the case where the tla change depends on the hackerlab
    > change.  You don't want the tla merge to succeed but the hackerlab merge
    > to fail.  This should actually be fairly easy to implement in tla-pqm, I
    > just haven't done it yet.

I'm a little skeptical about the idea of a fixed or default upstream
destination for a merge request.    I think that in general you have:


        From the merge request submitter:

                * baseline version or revision for the patch
                * merge formula (cherry-pick, star-merge, star-merge
                  --reference, etc.)

        From the merge request receiver:

                * what to apply that to

and its from the combination of those that the actual tla commands for
a merge are derived.

The idea is roughly that the submitter promises that if you start with
the indicated baseline and follow the merge fomula, you get a clean
merge and a `what-changed' against the baseline summarizes the merge.

What the receiver does with that info can vary.   In other words I
perceive the potential here to design a little language for "merge
formulas" but I haven't tried to come up with such a language yet.

I do kind of like the idea of some meta-info, _somewhere_, that
records the "expected patch flow".   That works both ways:  it can
streamline my forming a merge-request and it can also tell me when my
own branches have fallen behind.

I'm not so sure, though, that that meta-info is either per-archive or
per-tree.  Maybe it's per-{user,archive,category,branch,version} where 
at least the last four of those can be wild-carded and substituted
into a template for what the upstream thing is called.

It'd be nice if a tool that collects merge-requests wasn't entirely a
point-to-point tool.   It'd be handy if I could import merge-requests
to you into my own pool of merge-requests.

    > From: Colin Walters <address@hidden>

    > On Thu, 2003-10-16 at 22:13, Tom Lord wrote:

    > > I think this is a good direction but it needs to cook more, along with
    > > the patch tracker foo.

    > Do you have any specifics?

I'm trying to suggest some ideas.  It's that I don't have lots of
solid specifics that causes me to say the whole tangle ought to "cook
more".   Don't let my overly ambitous ideas screw up pqm -- if
something fits in it fits in, if it doesn't it doesn't.


    > For example, would you accept patches to implement "submit-merge" in my
    > proposed form?  I think that actually the idea of submitting a merge
    > request is a fairly general one, and other types of arch process
    > management software could leverage the same architecture (dropping a
    > file into a queue or sending a GPG-signed email).

I don't see it as compelling, quite yet.


-t