On Tue, Mar 04, 2025 at 12:20:59PM -0800, Darrick J. Wong wrote: > On Mon, Mar 03, 2025 at 04:00:39PM +0100, Carlos Maiolino wrote: > > On Mon, Mar 03, 2025 at 03:05:47PM +0100, Christoph Hellwig wrote: > > > On Mon, Mar 03, 2025 at 11:42:12AM +0100, Carlos Maiolino wrote: > > > > The biggest change here is that for-next will likely need to be rebased > > > > more often than today. But also patches will spend more time under testings > > > > in linux-next and everybody will have a more updated tree to work on. > > > > > > FYI, what other trees do is to keep separate branches for the current > > > and next release, i.e. right now: for-6.14 and for-6.15 and merge those > > > into the for-next or have both of them in linux-next (e.g. for-linus and > > > for-next). In that case most of the time you don't need to rebase at > > > all. Instead you might occasionally need to merge the current into the > > > next tree to resolve conflicts, and Linus is fine with that if you > > > document the reason for that merge. > > Separate branches for 6.14 and 6.15 that then get merged into a for-next > is what I did when I had separate trains running at the same time. Most > of the time I just rolled the post-rc6 fixes into the next release, so I > usually only dealt with one at a time. > > (to some grumbling) > > > This is pretty much aligned with my intentions, I haven't looked close yet how > > other subsystems deals with it, but by a few releases now, I keep a > > xfs-fixes-$ver branch which I collect patches for the current version, so adding > > a new branch for the next merge window is what I aimed to do with > > xfs-6.15-merge. > > > > The question for me now lies exactly on how to synchronize both. You partially > > answered my question, although merging the current into next sounds weird to me. > > > > If I merge current into next, and send Linus a PR for each (let's say for -rc7 > > and in sequence for the next merge window), Linus will receive two PRs with > > possibly the same patches, and yet, on the merge window PR, there will also be a > > merge commit from -current, is this what you're describing? > > If I had a for-6.14 and a for-6.15 branch, I'd base the PRs off of those > branches, not the for-next branch itself. I see what you mean, but from another POV, you'd be basing a PR on top of one series of patches, not on top of everything. Today, what we have, is a relatively stable for-next branch, where we just really rebase when something goes wrong, so, usually, when I push things into for-next, I've had it tested for a big while. Per my conversations off-list (specially with hch), is that this shouldn't be the purpose at all of for-next, but a testing branch where (almost anything) can go wrong, within reason of course. Please correct me if I'm wrong here. At the same time, I wish we have a branch that everybody can work with, which contains 'everything' staged, ready to go, so I'd do all the merge between current and next release myself into such branch. I think having a branch ready for people to work with is a maintainer's job, and people shouldn't be bothered by trying to figure out which branch they should use to base their patches on top. I'm hoping to use the master's branch for that if nobody has any objection. Carlos > > > Thanks for the input. > > > > > > > > > > > > > Also, I'm still thinking how to handle pull requests I receive. I try > > > > hard to not change the commit hashes from the PRs, so I'm still not sure > > > > how feasible it will be to keep the same hash ids from PRs giving more often > > > > than not I'll need to rebase the next merge tree on the top of fixes for the > > > > current -RC and in some cases, on top of other trees with dependencies. > > > > > > With the above you just keep the pull requests as-is. > > > > > > > > > > Sounds reasonable > > Or you can ask the PR submitter to rebase off latest for-6.15 and handle > the merge themselves. > > --D
