[Mesa-dev] Stable release process

[Jason Ekstrand]

On Nov 15, 2016 11:07 AM, "Ian Romanick" <idr at freedesktop.org> wrote:
>
> On 11/14/2016 02:31 PM, Matt Turner wrote:
> > A long time ago, patch authors were tasked with cherry-picking their
> > patches to stable branches. Today we Cc
> > mesa-stable at lists.freedesktop.org and Emil rebases those patches onto
> > stable. Cc'ing the list happens even on patches sent for their first
> > review that are ultimately rejected, creating a lot of noise (and
> > presumably makes the mailing list less useful).
>
> When we first came up with the process several years ago, we had a
> couple goals that didn't always align.  The top two were:
>
> - Bug fixes shouldn't be missed from stable releases.
>
> - Individual developers shouldn't have to shepherd patches into stable.
>
> Secondary goals:
>
> - Reviewers should know when a fix is destined for stable.
>
> - Fixes that weren't initially marked for stable could be marked later.
>
> Using a separate mailing list seemed to meet all those goals.  Reviewers
> would know a patch was destined for stable due to the Cc.  Once a patch
> landed on master with the Cc, the developer could "forget" about it.  It
> was now in the hands of the stable maintainer.  It would also be easy to
> nominate a patch for stable after it landed on master by just sending it
> to the stable list.
>
> All the things that make it easy to get a patch in the stable queue also
> make it hard to get a patch out.  If a patch is rejected (never lands on
> master), it is still floating on the stable list.  If a patch lands but,
> after the fact, we decide it shouldn't go to stable, it's still tagged
> in the git log (the .cherry-ignore file helps with this).

This sounds a lot like the one thing patchwork is good for.  Would setting
up patchwork for the stable list solve some of these problems?  Then we
would always know what's on it and the stable maintainer would be
responsible for keeping it tidy.  It's not a lot of patches so the burden
wouldn't be large.  It may even make the cherry picking easier.

> > Initial questions:
> >
> > Is the mesa-stable@ mailing list useful (other than as a tag in a
> > committed patch)?
> >
> > What do "nominated" and "queued" in the stable release candidate
> > announcements actually mean?
> >
> > Should driver maintainers cherry-pick patches to stable on their own?
>
> I think there's value in having a single gatekeeper for stable.  It's
> common for bug fixes to touch common code.  The single gatekeeper has a
> responsibility to ensure that other drivers don't break, etc.
>
> There are some things we could try that are somewhere between the
> current system and multiple pushers.  Other projects have a model where
> subsystem maintainers send branches to the next level up maintainer to
> merge.  Something similar to that might work.  We have to be careful
> that we don't pick a system that only works well for AMD and Intel.
>
> > Regardless of the outcome of that question, I think we would the
> > process would be more transparent and predictable if patches were
> > incorporated into the branch over time rather than all at once a few
> > days before the release.
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161115/00afeb48/attachment.html>