Gerrit

> "keep in our radar"

What does would mean? Say, find-owners would be voted to be in this category: "non-core (high-priority)" and will be places on our radar.

Who would go ahead and fix broken CI (for years) for this plugin, tracked in this https://crbug.com/gerrit/12512?

I think one huge problem that can be easily fixed with the current plugin state: most of them are lucking stable branches. For one, some plugins are not maintained any more, for another, the current maintainer disagree with the idea of regularly cutting of the stable branches. We should re-consider this policy, and always create stable branch for all plugins that known to still work and be maintained.

> > "keep in our radar"
> What does would mean?

IMHO keeping in our radar means two things:
1) For a stable release: validate that the plugin still works (and fix if it doesn't) when we change a Gerrit public API in a stable branch. (Dave Borowitz was used to do so with a list of plugins in his radar, which included also some of my plugins)
2) For a new release: validate that the plugins still works (and fix if it doesn't) when we make a brand-new release.

Does that make sense?

> Say, find-owners would be voted to be in this category: "non-core (high-priority)" and will be places on our radar.

This is an hypothesis of course, because my proposal is to run a survey to get that list :-)

> Who would go ahead and fix broken CI (for years) for this plugin, tracked in this https://crbug.com/gerrit/12512?

The Gerrit maintainers IMHO, what do you think?

> I think one huge problem that can be easily fixed with the current plugin state: most of them are lucking stable branches.

That's a different point I believe: does a stable branch for a plugin give any guarantee that it won't brake in stable branches *AND* it won't brake for future releases? The answer is NO in my personal experience.

If a stable branch of Gerrit makes a non compatible change on a public API or upgrade one of its dependencies (e.g. JGit), the plugins may break, also if they have a stable branch themselves.

But that will be a point of discussion *after* we agreed to make a survey and introduce a process on how to "keep in our radar" the high-priority plugins.

At the moment, we only have core (= maintained by the Gerrit maintainers) and non-core (= maintained by the plugin's maintainer).

Plugins are of varying importance depending on everyone's deployments and diverse topologies.
Even authentication plugins are not all of equal importance to the major deployments.

I think it may be hard to come up with one community-wide prioritized list of plugins.
A survey might still reveal dominant or unanimous non-core plugins though, yes.
However that potential list should not make other plugins second-class citizens.
Less popular plugins are often still essential to some community members.

Now for the unrelated or so:
I agree with the idea that plugins should have explicit stable branches, for every supported Gerrit version of theirs.
Even if some of those branches end up being only trivial upstream merge hops.
-At least they'd explicitly state their build compatibility expectation.

This becomes necessary for plugins supporting bazel standalone, as the branch then holds a specific API version.
For in-tree, explicit stable branches would help select the proper head git ref, for each plugin under each core tree.
No branch is an all-time compatibility guarantee, but at least it makes the expectation explicit.
Branches are usable versioned references similar to tags or labels, here; with their own parts to merge up or "not".

[Empty comment from Monorail migration]

Consider: project-download-commands plugin.

There is no stable branches at all. I tried to figure out where it can still be built, and was
only able to create stable-3.1 branch with try-and-error approach.

Moreover, there were build jobs defined for every stable-branch. All jobs were broken.
That git reverted in this CL: [1]. Now, de-factor this plugin cannot be used, I tried to
restore stable-3.1 build job in: [2]

Problem Statement: Say my site relies on this plugin in release-2.14/2.15/2.16 branch and now I upgrade to stable-3.0, that is still supported: what should I do?

Possible solutions:

Who is the maintainer of that plugin? According to the plugin matrix, gerrit core maintainers.

Solution 1:
Make the plugin work for every stable branch. So please, can someone from core gerrit maintainers fix that plugin to build/test on stable-3.0 branch?

Solutions 2:
Abandon that plugin. One reason Google opposed to promote new plugins to become core plugins, is because core team would have to take of that plugin. But even without being core plugin, the fact that plugin matrix is claiming that the core gerrit team is maintainer of that plugin (nad my issue that is questioning that decision) was rejected by Marco, would effectively mean, that Gerrit core maintainers have to fix that plugin.

Solution 3:
Declare that plugin as unsupported and inherently broken for older branches and only support it starting frm stable-3.1 branch. But that would effectively mean, that we should create stable-3.2 and so on for this (and other plugins?) to make sure it will not break in future.

[1] https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/268652
[2] https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/268851

> One reason Google opposed to promote new plugins to become core plugins, is because core team would have to take of that plugin. But even without being core plugin, the fact that plugin matrix is claiming that the core gerrit team is maintainer of that plugin (nad my issue that is questioning that decision) was rejected by Marco, would effectively mean, that Gerrit core maintainers have to fix that plugin.

 If the maintainers agree that they don't want to be listed as maintainers of gerrit plugins through their owner permission on the public plugins parent project I can change the plugins.py script to not consider the parent project for determining who is a plugin maintainer.

A non-core plugin maintained by Gerrit maintainers is a de-facto "no man's land": if it was supposed to be actively maintained by core maintainers is because it is a core plugin, otherwise it will always be at the bottom of the maintainers talk list.

My proposal with this ticket is to prepare a survey to ask the people which ones are the plugins they *absolutely* need to for their Gerrit setup to work.
(e.g. high-availability for a user that is already using two masters in prod)

 > If the maintainers agree that they don't want to be listed as maintainers of gerrit plugins through their owner permission on the public plugins
> parent project I can change the plugins.py script to not consider the parent project for determining who is a plugin maintainer.

+1 I'm in favour of this solution. The inherited owner permissions just mean that Gerrit maintainers are able to approve changes, but not that they maintain the plugin.

>> If the maintainers agree that they don't want to be listed as maintainers of gerrit plugins through their owner permission on the public plugins
>> parent project I can change the plugins.py script to not consider the parent project for determining who is a plugin maintainer.

>+1 I'm in favour of this solution. The inherited owner permissions just mean that Gerrit maintainers are able to approve changes, but not that they maintain the plugin.

+1 as well from my side. Being a "default maintainer" gives false expectations of "actively maintaining" the plugin, which is not, given the status, for example, of project-download-commands.

I pushed a change changing the generation of the plugin matrix accordingly
see https://bugs.chromium.org/p/gerrit/issues/detail?id=12805

Thanks guys and @Matthias.

@David, what does "(nad my issue that is questioning that decision) was rejected by Marco" mean?
What did I do, as I don't recall doing such a thing; what was that exactly?

> @David, what does "(nad my issue that is questioning that decision) was rejected by Marco" mean?
> What did I do, as I don't recall doing such a thing; what was that exactly?

https://bugs.chromium.org/p/gerrit/issues/detail?id=12805#c1

>> @David, what does "(nad my issue that is questioning that decision) was rejected by Marco" mean?
>> What did I do, as I don't recall doing such a thing; what was that exactly?

> https://bugs.chromium.org/p/gerrit/issues/detail?id=12805#c1

I see now. My intention in there was not rejecting but (trying to) confirm a related conclusion on the matter.
I was not against your view as such then, David.
-My handling of that Issue was not clear enough it seems.

Next time I think we should follow-up in the tracker upfront when such misunderstandings arise.
But thanks for having clarified that now :)

[Empty comment from Monorail migration]

Luca, are you still willing to own this task, or should we amend the issue otherwise?

Closing this, as no more feedback was provided after the above trailing one.

Apologies for not answering to your previous comment: I believe the issue is still valid, as we don't have yet a priority list.
Recently the HA plugin broke in Gerrit v3.3 (project cache eviction not working) and it went unnoticed until now :-(

We should also include the priority list of plugins when validating new releases.

Going to re-open this, unless you are pointing me to another issue :-)

Luca.

Thanks for your follow-up @Luca, no problem.
We CMs just met and groomed this as closable, but you just confirmed that we should keep this.

Feel free to amend the Owner field if you cannot work on this any time soon or so.

> Feel free to amend the Owner field if you cannot work on this any time soon or so.

I would like to propose this list in the forthcoming Gerrit v3.4 release, so that we have a set of plugins that we validate the new release E2E.
Using one plugin in that list would then give confidence to the users that those plugins work with the new version of Gerrit.

WDYT?

Sure, let's review your proposal once detailed through that upcoming v3.4 context. Thanks! :)

[Empty comment from Monorail migration]

Edits were made to reflect the following in Monorail: auto-CCs.