[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements
Dylan Baker
dylan at pnwbakers.com
Thu Mar 22 23:24:09 UTC 2018
Quoting Ilia Mirkin (2018-03-22 15:16:18)
> On Thu, Mar 22, 2018 at 6:00 PM, Dylan Baker <dylan at pnwbakers.com> wrote:
> > Quoting Ilia Mirkin (2018-03-21 17:39:14)
> >> 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.
> >
> > What do we do if two maintainers say yes, but it breaks another driver? I'm
> > asking because we've had these sort of problems in the past.
>
> An explicit NAK from any maintainer kills the whole thing. I believe
> this should apply to all patches, not just these "unfit and late
> nominations" category. At least that's what makes sense to me. Ideally
> the two warring factions will come to some agreement, but it's not the
> release manager's responsibility to resolve these conflicts.
>
> -ilia
That makes sense to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180322/efd27a08/attachment-0001.sig>
More information about the mesa-dev
mailing list