On Sun, May 2, 2021 at 11:04 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Sorry, I fat-fingered a thing and used gcc-9, which disables CONFIG_KASAN.
My point is that linux-next would have caught it.
And that commit _was_ in linux-next.
But it was rebased literally just hours before being sent to me, and
thus all the testing that it got was thrown away.
> > Use the previous release as a base (ie in this case 5.12)
>
> Not a problem for the first batch of patches, but what base do I use for
> the second and succeeding batches?
Well, the first batch is usually the biggest and most core one, and in
many ways the most important that it would have been a branch of its
own, and be something that has actually been tested as-is in
linux-next.
Ad to succeeding batches.. Optimally if they don't have any
dependencies on other trees or the first batch, they'd actually
entirely independent of the first batch, and just a separate patch
queue entirely, and tested as such in linux-next (and again on top of
some previous base).
But that kind of workflow would require you literally have multiple
separate patch-queues that you test independently. That does sound
like a good idea, but it also sounds very much like a "git topic
branch" model, and I think quilt basically is a "single series" tool,
not able to handle multiple independent series?
I don't know quilt, and a quick google of "multiple independent quilt
patch series" ended up at a web page by Andreas Grünbacher that was so
old that it was in Latin1 and doesn't even display properly on any
modern browser.
Which is a statement in itself, but whatever.
I'd actually be perfectly ok with being told that subsequent patches
be based on top of your previous patch series: I already create a
branch called "akpm" for applying all your patches, and while right
now it's a temporary branch that gets removed after I merge it, I
could easily just keep it around - and then apply your next series on
top of it.
So the only issues would be the things that actually end up being
dependent on other branches in linux-next:
> Maybe 10% of the patches I carry are based on changes which are in
> linux-next.
These are the ones that you'd have to keep separate, in order to not
rebase the patches that _aren't_ based on linux-next changes..
Again, I don't know how to do that with quilt (and iirc, you aren't
actually using quilt, you're using your own extended version?)
The quilt man-page does have some signs that there can be multiple
series of patches (wording like "current series" vs "another series",
and "Different series files can be used.."), but the actual quilt
commands don't really show much sign of switching between different
patch series. So I get the feeling that it's more of a "theoretically
possible" thing rather than something that is actually supported by
the tooling natively.
Linus
