[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] tla patch queue manager 0.1
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] tla patch queue manager 0.1 |
Date: |
Tue, 7 Oct 2003 10:07:13 -0700 (PDT) |
> 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