From: alexander.levin@verizon.com
To: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Emil Velikov <emil.l.velikov@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
ML dri-devel <dri-devel@lists.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)
Date: Tue, 21 Nov 2017 18:02:06 +0000 [thread overview]
Message-ID: <20171121180204.i5b4w5ijbbigyxch@sasha-lappy> (raw)
In-Reply-To: <CA+5PVA6b=5trb3AM2KoUtf-VhHQqqA8RWKi0s-8rFRDyZiBnsQ@mail.gmail.com>
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
next prev parent reply other threads:[~2017-11-21 18:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 11:21 Emil Velikov
2017-11-20 12:39 ` Daniel Vetter
2017-11-20 13:13 ` Daniel Vetter
2017-11-20 20:57 ` Alex Deucher
2017-11-20 21:39 ` Dave Airlie
2017-11-21 8:55 ` [Intel-gfx] " Daniel Vetter
2017-11-21 7:58 ` Greg KH
2017-11-21 8:51 ` Daniel Vetter
2017-11-21 15:07 ` alexander.levin
2017-11-21 17:09 ` Josh Boyer
2017-11-21 17:18 ` Greg KH
2017-11-21 18:02 ` alexander.levin [this message]
2017-11-21 17:55 ` Emil Velikov
2017-11-22 14:35 ` alexander.levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171121180204.i5b4w5ijbbigyxch@sasha-lappy \
--to=alexander.levin@verizon.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jwboyer@fedoraproject.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®