---- On Wed, 20 Nov 2019 08:21:29 -0600 Matt Riedemann <mriedemos@gmail.com> wrote ----
On 11/20/2019 1:18 AM, Zane Bitter wrote:
Because the core stable team is necessarily not as familiar with the review/backport history of contributors in every project as the individual project stable team is with contributors in each project.
This is assuming that each project has a stable core team already, which a lot don't, that's why we get a lot of "hi I'm the PTL du jour on project X now please make me stable core even though I've never reviewed any stable branch changes before".
With Tony more removed these days and I myself not wanting to vet every one of these "add me to the stable core team" requests, I'm more or less OK with the proposal so that it removes me as a bottleneck. That might mean people merge things on stable branches for their projects that don't follow the guidelines but so be it. If it's a problem hopefully they'll hear about it from their consumers, but if the project is in such maintenance mode anyway that they can break the stable guidelines, then they might not have many external consumers to complain anyway. Either way I don't need to be involved.
This is the main problem going to be and I am worried about it. We had the great stable policies with a dedicated team maintaining it well. 'great' and 'well' I am writing from the user perspective where they get applicable backport which does not break their within-in-release upgrade. If backport is delayed it is fine for them as compared to breaking backport. OpenStack has a very well known problem of inconsistent APIs. Inconsistency is from usage, interop, debug perspective. All projects define its own definition of APIs (new API, changes, discoverability etc) which we say it is fine because that project wants to do that way but the user faces the problem. We have not solved this problem yet due to various reasons. IMO, this problem could have solved or minimized if we had "Single mandatory way to write and maintain your API and central team to very that" from *starting* instead of project decide its own way or recommended guidelines only. The same case is for stable backports, we have a "Single mandatory way to backport the changes and central team to verify that". And due to that, OpenStack is more stable on the backports business. Why we are changing that? Stable backport is more of maintaining the quality and no-break things than merging a large amount of backports and *fast*. -gmann
So sure, +1 from me on the proposal given nova can still do what it's already been doing with a specific stable maint core team ACL in Gerrit.
--
Thanks,
Matt