On 21.10.22 11:40, Neil C Smith wrote:
On Thu, 20 Oct 2022 at 22:48, Michael Bien <[email protected]> wrote:
On 20.10.22 21:33, Neil C Smith wrote:
NB 9 and 10 - shared plugin catalog.
NB 11.0 - 11.3 - shared plugin catalog.
NB 12.0 - 12.6 - shared plugin catalog.
NB 13 and 14 - shared plugin catalog.
right. Catalog sharing happened already a few times which created a
similar scenario as the proposed one.
If by "a few times" you mean every Apache NetBeans release until the
current one?! :-)

Only 3 out of those 15 releases above did not automatically inherit
the plugins from the release before.  The similar scenario to the
proposed has happened for the majority of our releases.

   2) maintainers are asked to test their plugins during the RC phase and
press request verification if it is compatible
...
The assumption here is that most plugins will just work (positive bias).
But a small number will be filtered out over time (with the option to
come back).
 From a releases management perspective, what I'd like to see is a
fully populated plugins repository the moment we're ready with rc1.

well, this was my first suggestion but it met resistance :)

I would just leave everything verified. The community could filter problematic plugins out which are not updated.

positive bias -> most plugins should keep working, those which don't can be probably identified


I'm not sure of the best way we can get there, but it has to work
reliably and without undue extra work from our side and plugin
authors' side.

agreed. I think a step in the right direction is to notify maintainers about the requirement to test their plugins and press the button. Everything else can build on top of that. If this would be somehow possible within this release cycle - this would be awesome.

If the workload for the verifiers could be reduced by auto-verifying new verification requests of plugins which were verified in past - even better.


I still wish we'd gone down the route of managing plugins via a git
repository!  It would have simplified and opened up this process to
all committers.

interesting idea! It would have had the benefit that all imaginable tooling would be already there and maintainers know how to use it.


should we write some of this down (the next 1-3 uncontroversial steps)? I have the feeling the exact same discussion happens during each release.

best regards,

michael


Best wishes,

Neil



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



Reply via email to