Re: [Gnu-arch-users] Re: named patches, patch order, patch queue manager (was: the infinite thread)

[Davide Libenzi]

On Wed, 1 Oct 2003, Tobias C. Rittweiler wrote:

> On Tuesday, September 30, 2003 at 9:14:56 PM,
>     Davide Libenzi <address@hidden> wrote:
>
> > On Tue, 30 Sep 2003, Tom Lord wrote:
> >
> > [...] So I agree that named patches are handy -- I just wonder if
> > they aren't best seen as a layer _over_ arch. [...]
> >
> > What about something like virtual patches ? Example :
> >
> > [...]
> >
> > A fetch of "sched-fix-starvation" from the maintainer will trigger
> > fetching the list of patches. [...]
>
> Your virtual patches are, essentially, exactly what Tom sees as `named
> patches' AFAICS.
>
> So you see, your request about named patches has got confirmation to
> be useful, but nevertheless the quoted part of Tom's mail indicate
> (rightfully, IMHO) that you won't find this feature in tla as it's
> really something which should be put on top of arch.

Nope, they're two different things. Virtual patches are a way for you to
start working on something like "vm-fix-superflous-tlbflush", by starting
(like I usually do) with "vm-fix-superflous-tlbflush-A1". Like Tom was
saying you might end up having different named patches that will be
generated by multiple revision with, for example, the maintainer :

vm-fix-superflous-tlbflush-A1
vm-fix-superflous-tlbflush-A2
vm-fix-superflous-tlbflush-B1
vm-fix-superflous-tlbflush-B5

Now, after multiple talks with the merge-man I'd like to be able to say:
"Hey get vm-fix-superflous-tlbflush from my tree, is what we agreed on".
Now there are (at least) two ways to do this. You have the concept of
virtual patch:

$ tla vp-create vm-fix-superflous-tlbflush
$ tla vp-add vm-fix-superflous-tlbflush vm-fix-superflous-tlbflush-A1 ...

Basically this create a directory inside the revisions directory named
vm-fix-superflous-tlbflush that will contain a file ++virtual-patch with
this content:

vm-fix-superflous-tlbflush-A1
vm-fix-superflous-tlbflush-A2
vm-fix-superflous-tlbflush-B1
vm-fix-superflous-tlbflush-B5

Doing a raplay on vm-fix-superflous-tlbflush will trigger a get of:

vm-fix-superflous-tlbflush-A1
vm-fix-superflous-tlbflush-A2
vm-fix-superflous-tlbflush-B1
vm-fix-superflous-tlbflush-B5

Also, if arch would maintain the full qualified name of the remote patches
merged, you could trigger multiple times an raplay and arch will be able
to collect only missing pieces. The other way, somehow simpler to do this,
is to have something like:

$ tla raplay vm-fix-superflous-tlbflush-*

It is very simple to implement (once you have named patches), even if I
slightly prefer the first implementation. About named patches, there're
two ways to do it AFAICS. One is to have (like I was saying before) patch
directories to have the same patch name and rely on a ++patch-order file to
find out the patch order. The other one (that is maybe simpler to
implement since it plugs on the current implementation) is to have a file
++patch-names inside the patch revisions directory that lists:

vm-fix-superflous-tlbflush-A1   patch-134
vm-fix-superflous-tlbflush-A2   patch-163
vm-fix-superflous-tlbflush-B1   patch-192
vm-fix-superflous-tlbflush-B5   patch-211

The other important issue I was talking about is IMHO maintaining fully
qualified patch names across syncs. This would help a lot in simplifying
algorithms for cross merging.


> Best is you wait until Andrew finishes his draft about the patch queue
> manager which this named patch thingy can be a part of. Or if you can't
> wait, code yourself... :-)

It's not really urgent but I believe it is useful. I never had problems
doing things by myself ;) ... but adding code is always bad if there're
other simple ways to do the same thing. This is way you post to mailing
lists instead of closing yourself inside the dark-chamber with your
keyboard.



- Davide