On Tue, Nov 21, 2017 at 12:09:33PM -0500, Josh Boyer wrote: > On Tue, Nov 21, 2017 at 10:07 AM, <alexander.levin@xxxxxxxxxxx> wrote: > > On Mon, Nov 20, 2017 at 11:21:52AM +0000, Emil Velikov wrote: > >> - 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. > > > > I agree with this one, and it'll definitely happen. The story behind > > this is that this is all based on Julia Lawall's work which is well > > documented in a published paper here: > > > > https://soarsmu.github.io/papers/icse12-patch.pdf > > > > I have modified inputs and process, but it essentially is very similar > > to what's described in that paper. > > > > While I have no problem with sharing what I have so far, this is > > still very much work in progress, and things keep constantly changing > > based on comments I receive from reviewers and Greg, so I want to > > reach a more stable point before trying to explain things and change > > my mind the day after :) > > > > If anyone is really interested in seeing the guts of this mess I > > currently have I can push it to github, but bear in mind that in it's > > current state it's very custom to the configuration I have, and is > > a borderline unreadable mix of bash scripts and LUA. > > > > Ideally it'll all get cleaned up and pushed anyways once I feel > > comfortable with the quality of the process. > > > >> - Make the autoselect nominations _more_ distinct than the normal stable ones. > >>Maintainers will want to put more cognitive effort into the patches. > > > > So this came up before, and the participants of that thread agreed > > that adding "AUTOSEL" in the patch prefix is sufficient. What else > > would you suggest adding? > > 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? As much fun as that might be, that's going to cut _way_ down on the number of real bugfixes that get applied to the kernel due to the lag in responses. I review all of these patches, as does Sasha, so I think let's stick with the existing mode of "it passes our review so let's include it". Becides, the testing that everyone is doing on the stable kernels should catch any real problems, right? :) But if any subsystems don't want us to include patches this way, just let us know. It seems the graphics developers don't want their patches backported, which is fine, we will leave them alone... thanks, greg k-h _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
