Message-ID: <CACvgo53qTV6-6jOGCuaOVBGb5taEoW6zx0Jd1jK1vC5jEYMobQ@mail.gmail.com>
Date:   Mon, 20 Nov 2017 11:21:52 +0000
From:   Emil Velikov <emil.l.velikov@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     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>,
        alexander.levin@...izon.com,
        ML dri-devel <dri-devel@...ts.freedesktop.org>
Subject: 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)

Hi all,

Since I'm going slightly off-topic, I've tweaked the subject line and
trimmed some of the conversation.
I believe everyone in the CC list might be interested in the
following, yet feel free to adjust.

Above all, I'd kindly ask everyone to skim through and draw their conclusions.
If the ideas put forward have some value - great, if not - let my email rot.

On 17 November 2017 at 13:57, Greg KH <gregkh@...uxfoundation.org> wrote:

>>
>> I still have no idea how this autoselect picks up patches that do *not*
>> have cc: stable nor Fixes: from us. What information do you have that we
>> don't for making that call?
>
> I'll let Sasha describe how he's doing this, but in the end, does it
> really matter _how_ it is done, vs. the fact that it seems to at least
> one human reviewer that this is a patch that _should_ be included based
> on the changelog text and the code patch?
>
> By having this review process that Sasha is providing, he's saying
> "Here's a patch that I think might be good for stable, do you object?"
>
> If you do, great, no harm done, all is fine, the patch is dropped.  If
> you don't object, just ignore the email and the patch gets merged.
>
> If you don't want any of this to happen for your subsystem at all, then
> also fine, just let us know and we will ignore it entirely.
>
Let me start with saying that I'm handling the releases for Mesa 3D -
the project providing OpenGL, Vulkan and many other userspace graphics
drivers.
I've been doing that for 3 years now, which admittedly is quite a
short time relative to the kernel.

There is a procedure quite similar to the kernel, with a few
differences - see below for details.
We also autoselect patches, hence my interest in the heuristics
applied for nominating patches ;-)

That aside, here are some things I've learned from my experience.
Some of those may not be applicable - hope you'll find them useful:

 - Try to reference developers to existing documentation/procedure.
Was just reminded that even long standing developers can forget detail X or Y.

 - CC developers for the important stuff - aka do not CC on each accepted patch.
Accepted patches are merged in pre-release branch and a email with
accepted/deferred/rejected list is sent.
Patches that had conflicts merging, and ones that are rejected have
their author in the CC list.
Rejected patches have brief description + developers are contacted beforehand.

 - Autoselect patches are merged only with the approval from the
respective developers.
IMHO this engages developers into the process, without distracting
them too much.

It is by no means a perfect system - input and changes are always appreciated.


That said, here are some suggestions which should make autosel smoother:

 - Document the autoselect process
Information about about What, Why, and [ideally] How - analogous to
the normal stable nominations.
Insert reference to the process in the patch notification email.

 - Make the autoselect nominations _more_ distinct than the normal stable ones.
Maintainers will want to put more cognitive effort into the patches.


HTH
Emil

Powered by blists - more mailing lists