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-sta...@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@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
