On Tue, Mar 6, 2018 at 2:34 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > So while others explore ways of improving the testing, let me propose > a few ideas for improving the actual releasing process. > > > - Making the current state always visible - have a web page, git > branch and other ways for people to see which patches are picked, > require backports, etc.
Yes please! A git branch that's available (and force-pushed freely) before the "you're screwed" announcement is going to help clear a lot of things up. > > - Per team maintainer - each team has person (a few people) to check, > coordinate and remind people for high priority bugs and backports. Yes! I think this role is highly necessary, but not for the reasons you outline here. My main issue thus far with the stable release process has been that I don't appear to have any control over what patches are included in a particular release. Reasons for rejection have varied from "well, there will be another release in 2+ weeks" to "this patch doesn't fit some arbitrary criterion". What I'd like to propose is a system where the team maintainer is able to request any particular patch to be included in a stable release (as long as it's done by a certain pre-announced deadline, which happens *after* the initial release nominations email). If a release manager disagrees, they can make that disagreement known, but it's ultimately up to the team maintainer for driver code. If it's in shared code (i.e. not driver-specific - winsys, core mesa, state trackers used by multiple drivers), the override would be 1 additional team maintainer acking, and conversely any team maintainer would be able to nak it (so the condition in case of disagreement would be at least 2 team maintainers in favor, and 0 against). As you may know, I've stopped tagging things for stable since a while back since it seems completely pointless - nothing I can do to actually cause a patch to be included in a release. Telling people to just use HEAD seems way more reliable. I'm not particularly happy with this arrangement, but it's at least supportable. Hopefully others here agree with me. Otherwise I'll just go back to doing what I'm doing (and perhaps my contribution level has dropped sufficiently to not worry about it). Cheers, -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
