linux-kernel - Re: linux-next: Signed-off-by missing for commit in the drivers-x86 tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 24 Aug 2017 13:56:10 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: linux-next: Signed-off-by missing for commit in the drivers-x86
 tree

On Sat, Aug 05, 2017 at 02:58:29PM -0700, Darren Hart wrote:
> On Thu, Aug 03, 2017 at 08:50:06AM -0700, Darren Hart wrote:
> > On Wed, Aug 02, 2017 at 06:06:20PM -0700, Linus Torvalds wrote:
> > > On Wed, Aug 2, 2017 at 5:28 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > > >
> > > > I would say that if you rebase someone's commit(s), then you are on the
> > > > "patch's delivery path" and so should add a Signed-off-by tag.
> > > 
> > > Yeah, I agree. Rebasing really is pretty much the exact same thing as
> > > applying a patch.
> 
> I will be away for a few days, but will follow up on this when I return.
> In the meantime, my plan is to leave the current for-next branch alone
> rather than rebasing it to fix the previous rebase which resulted in the
> mixed committer/signoff issue Stephen's new test identified.
> 
> I just want it to be clear I'm not ignoring the issue, but rather
> planning on addressing it in commits going forward - based on the
> results of the discussion below.
> 

OK, with no additional feedback here, Andy and I have discussed and we will
adapt our process by using individual review branches which 0-day can pull from
which are considered transient and mutable. After this, the patches will be
added to the common testing branch, which will now be fast-forward only [1].
After a short period, testing will move to for-next and fixes branches in
preparation for pull-requests, just as before.

Thanks,

1. We may eliminate the testing branch as it may not offer any value over
   for-next, but we'll work through at least one release cycle before doing
   so.

-- 
Darren Hart
VMware Open Source Technology Center