[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] tla-pqm 0.2
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] tla-pqm 0.2 |
Date: |
Fri, 17 Oct 2003 08:21:00 -0700 (PDT) |
> 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
- Re: [Gnu-arch-users] tla-pqm 0.2, (continued)
- Re: [Gnu-arch-users] tla-pqm 0.2, Tom Lord, 2003/10/16
- Re: [Gnu-arch-users] tla-pqm 0.2, Colin Walters, 2003/10/16
- [Gnu-arch-users] Re: tla-pqm 0.2, Miles Bader, 2003/10/16
- Re: [Gnu-arch-users] Re: tla-pqm 0.2, Colin Walters, 2003/10/16
- Re: [Gnu-arch-users] Re: tla-pqm 0.2, Paul Hedderly, 2003/10/17
- Re: [Gnu-arch-users] Re: tla-pqm 0.2, Tom Lord, 2003/10/17
- Re: [Gnu-arch-users] Re: tla-pqm 0.2, Colin Walters, 2003/10/17
- Re: [Gnu-arch-users] Re: tla-pqm 0.2, Tom Lord, 2003/10/17
- [Gnu-arch-users] Re: bugs-closing (was: tla-pqm 0.2), zander, 2003/10/17
- [Gnu-arch-users] Re: tla-pqm 0.2, Pau Aliagas, 2003/10/17
- Re: [Gnu-arch-users] tla-pqm 0.2,
Tom Lord <=
- [Gnu-arch-users] Extension language, Mark A. Flacy, 2003/10/16
- Re: [Gnu-arch-users] Extension language, Colin Walters, 2003/10/16
- Re: [Gnu-arch-users] Extension language, David Brown, 2003/10/16
- Re: [Gnu-arch-users] Extension language, Colin Walters, 2003/10/16
- Re: [Gnu-arch-users] Extension language, Tom Lord, 2003/10/17
- Re: [Gnu-arch-users] Extension language, Colin Walters, 2003/10/17
- Re: [Gnu-arch-users] Extension language, Stephen J. Turnbull, 2003/10/16
- Re: [Gnu-arch-users] Extension language, Joshua Haberman, 2003/10/17
- [Gnu-arch-users] Re: Extension language, Miles Bader, 2003/10/17
- Re: [Gnu-arch-users] Extension language, Stephen J. Turnbull, 2003/10/17