Ilia Mirkin <imir...@alum.mit.edu> writes: > 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.
I agree that early information is good. I don't agree that anyone should force push. Release branches need to be protected. Proposed release branches should only accept patches that have already been vetted by the process on mesa master. I would propose: - Patches are applied to proposed stable branch by automation when the associated commit is pushed to master. The existing commit message annotations drive this process. There must be zero ambiguity in the annotations (eg which stable branches need the patch). - Committer is responsible for ensuring that the automation executed. - Failure-to-apply generates mail to release managers and committer. The committer *should* have been able to test that the commit would not apply before pushing the patch to master, and should get dinged for this. - Failures to apply are resolved by committer, who must backport. Each backported commit references associated patch(es) on master in commit message. Backport is submitted by committer to release managers in PR or email. - CI Automation immediately builds/tests the proposed stable branch whenever it changes. Release managers verify the results. - Any CI failures are resolved by force-pushing the series off of the proposed branch. Release manager communicates status to committer. I think automation could be implemented to generate proposed stable branches on an arbitrary branch point in a local git repo. Including this policy mechanism in our git tree would make the process transparent, verifiable, debuggable, and extensible. Separately, I think we want to limit the ability of release manager to unilaterally change the stable build. Release managers should not author any new commit in the stable branch that is not reviewed by another release manager, from a different company. >> - Per team maintainer - each team has person (a few people) to check, >> coordinate and remind people for high priority bugs and backports. I've been doing this for Intel. Developers are on the hook to fix their bugs, but you can't make them do it. They have many pressures on them, and a maintainer can't make the call as to whether a rendering bug is more important than day-1 vulkan conformance, for example. We could heighten the transparency of what is blocking the build by publicizing the authors of bisected blocking bugs to Phoronix, which might get things moving. > 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". If the patches are immediately merged to proposed stable branches, then they should be included by default. It makes sense to have a standard window by which patches must be applied before a release. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
