Re: [Gnu-arch-users] tla patch queue manager 0.1

[Tom Lord]

    > From: Robert Anderson <address@hidden>

    > On Mon, 2003-10-06 at 19:06, Colin Walters wrote:
    > > Hi,

    > > After today's discussion about patch queue managers on IRC, I thought to
    > > myself that a simple one should be pretty easy to write.

    > If you could, I have absolutely no idea what a "patch queue
    > manager" is.  Can you describe what problem it solves, and how?


As others have pointed out, good question :-)

What I would like in this area is fairly banal but hugely detailed:  I
want a kind of "clerk".   

The kinds of "automated merging stuff" I've heard Andrew talk about
strikes me as potentially very useful -- but it isn't quite something
I have a personal need for at the moment.

I find myself having to merge changes from a fair number of archives
(probably too many but that's another story).  This gives rise to a
need for a fair amount of bookkeeping and shuffling trees around.  For
example:

1) I manage local mirrors for most of these sources.  Updating those
   mirrors is logically triggered by various events (e.g., new bug in
   the bug tracker; some email I just got; an IRC conversation....).

   For each archive I have a few policy choices: how to handle
   cachedrevs, whether to limit the scope of my mirror, etc.

   It'd be swell to have a little database of my policies, fed
   automatically with input from email etc, which keeps my mirrors
   up-to-date at the push-of-a-button or less.   It should be able 
   to tell me when I last mirrored, whether or there's new stuff I
   haven't yet mirrored, etc.


2) For each contribution, I have to go through several steps to 
   process the merge.   Perhaps I want to see the tree as the
   contributor sees it;  perhaps I want to review the changesets;
   perhaps I want to review the changeset that would be applied by a
   merge, etc.

   To an extent, the process is "contributor specific" -- different
   steps for different contributors;  to an extent it's change
   specific.

   To do these steps "by hand", I manage a lot of temporary
   directories.  The high level intention ("i want to review what that
   merge would change") has a pretty low-level expression ("make room
   in ~/test; create a subdir;  look up that guy's archive name again,
   get stuff; merge; what-changed ...").

   It'd be nice to have a tool that did that low-level stuff for me,
   and that kept around a catalog of what scratch dirs I've got going
   and what each one is.


3) Sometimes I want to know the answer to various questions:  what
   changes are "pending";  what notes have I made about them;  
   etc.

   The Savannah bug tracker is serving in this role right now but 
   it would be hard to come up with a clunkier interface to it 
   without it being completely useless.   (This is mainly because the
   bug tracker wasn't designed for arch purposes and partly because 
   it does all of its work server-side.)


All of that bookkeeping and file management is regular enough that I
think it could be heavily automated.   It's one of the few areas where
I think a good GUI would really help -- simply because the "data set"
(all the archive names, the list of pending merges, the list of
scratch dirs, etc) is sufficiently large that I really want menus of
it to pick things off from.

Work-flow patterns are sufficiently varied that I'm increasingly
thinking:

a) Yes, arch really could benefit from a good scripting language.

b) The most effective way to build good GUI tools here would be 
   to make lots of components (e.g., "mirror status browser")
   that can be glued together with a little bit of scripting.

-t