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

[Davide Libenzi]

On Tue, 30 Sep 2003, Tom Lord wrote:

>     > From: Davide Libenzi <address@hidden>
>
> (Please don't quote so much. :-)

If it is for the name length I can do nothing about it ;) While if it is
for the amount of spaces it is not not my MUA, Pine adds only one space in
my configuration.



>   Why is that?   In general, I don't think you should expect
>   "sched-fix-starvation-H1" to be a single revision -- it won't be
>   patch-243 -- it may span several patches.
>
>   In this example, suppose the maintainer said "that's crap; change it
>   thusly...".  If the change is on it's own branch, you can just
>   commit changes to that branch.
>
>         linus' tree:            sched-fix-starvation-H1 tree:
>         ------------            -----------------------------
>         ...
>         patch-I         -------> base-0
>
>         ...                      ...
>
>         patch-J                  patch-A
>
>                                 "Hey, want to merge this?"
>
>         [looks at
>          delta(patch-J,patch-A)]
>         "Nah, that's crap"      "Ok, I'll fix"
>
>         ...                     ...
>
>         patch-K  ~~~merge~~~~~> patch-B (catch up to recent mainline changes)
>
>                                 ....
>
>                                 patch-C
>
>                                 "Better?"
>
>         [looks at
>          delta(patch-K,patch-C)]
>         "yes"
>
>         ...
>
>         patch-J  <~~~~merge~~~~ patch-C (still)
>
>
>
>   In addition to letting you commit incremental corrections to the
>   patch, this technique also allows you to star-merge.  For example,
>   although the name "sched-fix-starvation-H1" suggests a fairly small
>   change, let's pretend that it's a very large change that wants to be
>   made in a series of smaller steps.  If it's desirable for Linus to
>   merge just parts of the change early, at various milestones, then
>   there's a situation of back-and-forth merging as Linus merges in
>   milestones and you merge back to update the linus-tree baseline for
>   work on sched-fix-starvation-H1.  Classic star-merge stuff.

What about something like virtual patches ? Example :

$ ls sched-fix-starvation
++virtual-patch
$ cat ++virtual-patch
sched-fix-starvation-A0
sched-fix-starvation-A1
sched-fix-starvation-B0
sched-fix-starvation-B2

$ tla vp-create sched-fix-starvation
$ tla vp-add sched-fix-starvation sched-fix-starvation-A0 ...
$ tla vp-delete sched-fix-starvation-B1

A fetch of "sched-fix-starvation" from the maintainer will trigger
fetching the list of patches. Also, if patch names are preserved across
syncs that maintainer can fetch "sched-fix-starvation" multiple times and
arch will be able to fetch only missing pieces. Am I stoned ?
Also, my ++patch-order thingy was related to the fatch that arch currently
relies on names to sort patch order. And a ++patch-order file will give
you the order w/out a patch name order.




> ** what a patch queue manager should do
>
>   What might a patch-queue-manager be in this case?
>
>   One way to imagine it is to picture an unholy tangle of web
>   interfaces, GUI tools, email tools, bug trackers, and so forth with
>   the net effect that:
>
>   1) Linus has a "control panel" view showing changes people have
>      asked to have merged.   In this case it might say something like:
>
>      * sched-fix-starvation-H1
>        address@hidden
>                 Fix scheduler starvation
>        archive: address@hidden
>        version: [linux--sched-fix-starvation-H1--2.6]
>          (mirrored, up-to-date 9/30/03 6:12)
>
>
>        depends on: [fix-acpi-int-table]
>
>        bug ids:  [#14834], [#24892]
>
>        merges cleanly: [yes (linus--mainline--patch-1837)]
>        fixes regressions: n/a
>        [browse change] [browse thread] [prepare tree] [auto commit]
>
>    Where the "[...]" items are links.

I'm afraid I can't help you here since I don't know how Linus are Andrew
prefer to work. But this is more process-related stuff, and does not
involve arch's core functionalities.




- Davide