On Thu, May 10, 2018 at 06:03:22PM +0200, Jiri Kosina wrote: >On Wed, 9 May 2018, Daniel Vetter wrote: > >> >> Then, why don't we have a pre-integration tree for fixes? That would >> >> at least simply automated testing of fixes separately from new >> >> material. >> > >> >> Perhaps this has already been discussed, and concluded and it's not >> >> worth it, then apologize for my ignorance. >> > >> > I think this is an excellent idea, copying in Stephen for his input. >> > I'm currently on holiday but unless someone convinces me it's a terrible >> > idea I'm willing to at least give it a go on a trial basis once I'm back >> > home. >> >> Since Stephen merges all -fixes branches first, before merging all the >> -next branches, he already generates that as part of linux-next. All >> he'd need to do is push that intermediate state out to some >> linux-fixes branch for consumption by test bots. > >What I do for my trees is that I actually merge the '-fixes' branch (that >is scheduled to go to Linus in the 'current' cycle) into my for-next >branch as well. > >This has the advantage of (a) getting all the coverage linux-next does (b) >seeing any potential merge conflicts early > >Is this not feasible for other trees?
When Linus tags -rc1, -next will start filling up with commits destined for the next merge window. The resulting -next tree becomes very unstable, and very difficult to test. The idea behind next-fixes is to provide a tree that will contain fixes for the current merge window, which will generate a much more stable tree that users/bots could actually run and validate the fixes that will be merged in the upcoming weeks. Right now, with the method you've described, there is no easy way to test your '-fixes' branch even though the commits in there will be pulled in by Linus much sooner than your 'for-next' branch. You'll still get the same coverage from -next, but if you provide your -fixes branch seperately you'll also get more coverage for the fixes you're about to send to Linus.
