[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