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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171121180204.i5b4w5ijbbigyxch@sasha-lappy>
Date:   Tue, 21 Nov 2017 18:02:06 +0000
From:   alexander.levin@...izon.com
To:     Josh Boyer <jwboyer@...oraproject.org>
CC:     Emil Velikov <emil.l.velikov@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: Autoselect patches for stable (Was: Re: [PATCH AUTOSEL for 4.9
 36/56] drm/i915: Fix the level 0 max_wm hack on VLV/CHV)

On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote:
>The root of the concern seems to be around how the stable process
>currently works and how auto-selection plays into that.  When Greg
>sends out the RC, the default model of "if nobody objects, this patch
>will get included in the next stable release" works because a human
>already identified as that needing to be included.  So the review is
>looking for a NAK, but that's overriding another human's explicit
>decision with reasons.  For something that is auto-selected, people
>seem concerned that the default should be flipped.  Perhaps they'd be
>more comfortable if auto-selected packages required a human ACK before
>they are included?

Josh, I review the autogenerated list of commits, patch by patch,
myself, before sending it out. So there is a human involved in the
process.

Admittingly I'm not perfect and things do slip by once in a while. I
always look back and try to improve the process. Although the sample
size is small now (~600 commits proposed and merged using this method)
I don't belive the error rate is higher than the error rate for
"regular" stable tree commits.

I'd treat autoselection as a helper tool for the stable tree
maintainer rather than a magical way to produce stable commits (we're
not going to replace Greg with a robot any time soon).

-- 

Thanks,
Sasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ