On Sun, 2 May 2021 12:08:17 -0700 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > 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). The mm/ patches tend to be significantly interdependent. I try to separate things into mm/whatever subparts, but things are often quite smeary, both textually and conceptually. I don't send the whole mm/ queue in a single hit because it tends to be rather large. I could do so. > 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. I haven't found a need to do this. I presently identify 353 subsystems in the -mm patch queue. Most have zero patches in them most of the time. But apart from mm/ being all tangled up internally, I basically never see any overlap between these subsystems. So I stack 'em all up in the same series. > 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. OK, I'll do that this week and shall have a bit of a think. > 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?) Yes, my patch-scripts is quilt's grandfather and I continue to use and evolve it. > 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. Easy. You'd have a bunch of different series files and then do ln -s series-ocfs2 series ln -s series-procfs series etc to work on a particular series. Then for assembling an entire tree, have a master series-of-series file which contains the names of the various sub-series files, to define the stacking order: series-ocfs2 series-procfs ... Then cat $(cat series-of-series) > series and go for it. But as said, I haven't seen the need because they're almost always all orthogonal. A fairly recent series file is at https://ozlabs.org/~akpm/mmotm/series. It defines the applying order, the various subsystems, tags for which bits are to be included in linux-next, lots of notes-to-self, etc.
