gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Colin Walters
Subject: Re: [Gnu-arch-users] tla-pqm 0.2
Date: Thu, 16 Oct 2003 20:44:07 -0400

On Thu, 2003-10-16 at 20:19, Colin Walters wrote:
> Hi,
> 
> tla-pqm 0.2 is now available:

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. 
Essentially you just run "tla-pqm --run" manually instead of via cron,
so merges are still manual.  You can easily remove items from the queue
with 'rm'.  What would be nice is a way to export the merge requests
into HTML or something for easy viewing, or maybe even have a CGI
interface.

It also performs some of the functionality a "smart server" could, such
as validating precommit hooks, security, etc.  

However, tla-pqm isn't as "transparent" as a smart server would be.  I
think with a little support from tla, it could be fairly nice.

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}/=upstream 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.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]