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).
mesa-dev mailing list