Messages in this thread | | | Date | Fri, 11 May 2018 11:10:18 +0900 | From | Mark Brown <> | Subject | Re: [Ksummit-discuss] bug-introducing patches |
| |
On Thu, May 10, 2018 at 06:03:22PM +0200, Jiri Kosina wrote: > On Wed, 9 May 2018, Daniel Vetter wrote:
> > 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?
That's obviously best practice which I hope everyone who doesn't have a separate fix branch in -next is doing but it means that the fixes branch is not getting tested without the changes in your -next branch, and also reduces the coverage separate to other people's -next branches. This means that there's room for implicit dependencies to slip through. [unhandled content-type:application/pgp-signature] | |