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

[Andres Gomez]

On Mon, 2018-03-12 at 15:48 +0000, Emil Velikov wrote:
> On 12 March 2018 at 14:20, Andres Gomez <agomez at igalia.com> wrote:

[...]

> > On Tue, 2018-03-06 at 19:34 +0000, Emil Velikov wrote:
> > 
> > [...]
> > 
> > > A few other ideas that were also came to mind:
> > > 
> > >  - Round robin - where me/Igalia team will check for outstanding
> > >    patches, backports, etc.
> > 
> > I'm open to this. So far Juan and I have been doing this task while
> > being on relase duty but maybe it is better to explictly agree among us
> > (on a specific policy/shift rotation).
> > 
> 
> If there's an agreement to have a the per-team maintainer, this won't
> be needed... I think.
> 
> In the meanwhile, do share how you envision this?

Maybe I'm not understanding your proposal and you have something else
in mind but, as I see it, during the 2 weeks before a bugfix release
happens, this is what I was doing at the beginning of my working day:

 * Check the new landed patches. Identify the ones tagged for the
   stable branch and cross check them with the threads in the -stable
   ML.
 * Apply the nominated patches and let Travis-CI check they were not
   breaking the stable queue.
 * If any nominated patch was breaking Travis-CI or not applying into
   the stable queue (with a trivial conflict resolution), ping the
   author to ask for a backport, or clarification.
 * From the list of landed patches, identify non nominated ones that
   look like they should get into the stable branch. I did this is a
   loose more relaxed way.
 * Check in the -stable ML for stagnated threads and poke the authors,
   if needed. I did this more often when getting closer to the release
   date.
 * Nightly we (Igalia) have our own custom automation to run piglit and
   VK-GL-CTS with i965 and the software drivers in search of
   regressions in the stable queue.

> > >  - Have two distinct emails - an announcement and a second RFC that
> > >    lists the rejected patches and ones with outstanding backports
> > 
> > I don't think this would be really necessary, specially if we adopt
> > GitLab.
> > 
> 
> The idea is what to do, until we adopt it or any other solution. Would
> the split help people?

To be honest, so far we keep a review system based on a mailing list, I
think the -stable one suffices, without needing a new one. I'm not
opposing, though.

-- 
Br,

Andres