[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements

[Ilia Mirkin]

On Wed, Apr 4, 2018 at 12:12 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 22 March 2018 at 00:39, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> Just one bit of feedback, for the rest I either agree or have no opinion:
>>
>> On Wed, Mar 21, 2018 at 8:28 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>  * unfit and late nominations:
>>>     * any rejections that are unfit based on the existing criteria can
>>>       be merged as long as:
>>>        * subsystem specific patches are approved by the team
>>>          maintainer(s).
>>>        * patches that cover multiple subsystems are approved by 50%+1
>>>          of the maintainers of the affected subsystems.
>>
>> I don't think 50% + 1 is workable. That would mean for a core mesa
>> patch, one would have to get like 5+ people to ack it. Seems like a
>> lot. (And I suspect will lead to debates about how to count "affected"
>> subsystems.) IMHO 2 is enough, i.e. the maintainer that wants it, and
>> another maintainer who thinks it's reasonable.
>>
> The presumption of 5+ people is based that we'll get at least 8
> sub-system maintainers.

That's what I mean -- you'll get quibbling over who's involved and
who's not. There are like 10 different drivers, each with a separate
maintainer, and they can all be variously affected by a patch.
Figuring out how to "count" properly is complicated and seemingly
unnecessary. 2's enough - this isn't for a poll, it's for a "someone
other than me thinks this is important", to counter a "unfit and late
nomination" style argument from the release engineer. Getting a lot of
people to *actively* support a patch is a straight path to nothing
happening. Getting one other person (out of the maintainer group)
seems reasonable. These types of (social) systems are fairly
self-policing -- if we really do run into serious problems, they can
be addressed then.

  -ilia