On Mon, 2018-03-12 at 15:48 +0000, Emil Velikov wrote: > On 12 March 2018 at 14:20, Andres Gomez <ago...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev