[Mesa-dev] [RFC] Mesa 17.3.x release problems and process improvements
Andres Gomez
agomez at igalia.com
Tue Mar 27 10:17:33 UTC 2018
On Thu, 2018-03-22 at 16:24 -0700, Dylan Baker wrote:
> 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.
This also makes sense to me.
--
Br,
Andres
More information about the mesa-dev
mailing list