lkml.org 
[lkml]   [2018]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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]
    \
     
     \ /
      Last update: 2018-05-11 04:10    [W:2.876 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site