[Mesa-dev] Stable release process

[Ian Romanick]

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).

> 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
>