On Thu, May 10, 2018 at 6:47 PM, Sasha Levin via Ksummit-discuss <ksummit-disc...@lists.linuxfoundation.org> wrote: > 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.
I think you missed the "as well" in Jiri's response. When I create the bi-weekly renesas-drivers release (see e.g. https://www.spinics.net/lists/linux-renesas-soc/msg27350.html), there are some subsystems that manage to have several conflicts between their for-next branch and their fixes in Linus' tree almost every single release. Hence I strongly support merging your own fixes branches into your own for-next branch, and resolve the conflicts yourself, to keep your for-next branch conflict free. (Note that the last release linked above was very atypical: it was one of the very few (first one ever?) that didn't have any conflicts). Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
