On Thu, Mar 06, 2025 at 06:08:41PM +0100, Christoph Hellwig wrote: > On Thu, Mar 06, 2025 at 08:50:51AM +0100, Carlos Maiolino wrote: > > > 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. > > Well, while some subsystems have tons of topic branches that turns into > a mess really quickly. So what Darrick said makes the most sense in > general. There might be occasional corner cases where you'd want to > be more fine grained, but they should be very rare. > > > > > 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. > > I would expect for-next to have some amount of sanity testing. But the > idea is indeed to have the code integrated with other kernel changes > rather sooner than later. > > > > > 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. > > Using master is really confusing. > > As I said earlier and Darrick also said the most usual thing is > to have one branch for $CURRELEASE fixes and one for $NEXTRELEASE > development work. for-next is then a temporary merge of those two. > If you need $CURRELEASE changes in $NEXTRELEASE to avoid a mess, you > either rebase $NEXTRELEASE (usually earlier in the merge window) or > pull the $CURRELEASE into $NEXTRELEASE with a well-documented > merge commit message documenting why it had to be done. Eliminating the possibility of such messes is also why I avoided doing bugfixes and merge window prep whenever I could. ;) --D
