On 21.10.22 14:24, Neil C Smith wrote:
On Fri, 21 Oct 2022 at 12:43, Michael Bien <[email protected]> wrote:
well, this was my first suggestion but it met resistance :)
I know. I agree with you. My issue with the resistance, and some
points are definitely valid, is that it's based on a somewhat false
idea of what we've been doing for the last few years of releases.
I would just leave everything verified. The community could filter
problematic plugins out which are not updated.
We can't leave verified as far as I understand. We would need to bulk
verify everything, unless we go back to a shared catalog. And if we
go back to shared catalogs, we can't filter by release.
well, this somehow doesn't sound like a showstopper to me. Something
could just add that flag in some automated fashion, no?
Another idea: what if there would be two catalogs: one for verified
plugins and one for unverified. Unverified would be disabled by default
but would contain everything which didn't make verification yet.
This would:
- make it a user choice
- somewhat solve availability at release issues
- improve testability during RC (everything is there if you enable the
catalog)
There is also an argument to be made that a maintainer should probably
be able to upload a new version of a plugin without re-verification if
it was verified before to fast track updates.
One of the 5 available (and verified) plugins continues to cause issues.
Not only that, it causes them in areas you wouldn't expect. E.g empty
debugger views or files which can't be opened anymore.
As I understand this - there is a new version available which fixes some
(all?) of that - but it is not available from the plugin manager since
it has not been verified yet.
Verification doesn't seem to be a big barrier to break IDEs, we probably
should mention that somewhere so that this isn't seen as "stamp of
approval".
somewhat related I added a 'caused-by-plugin' label, so we can use that
to mark comparable issues it in future.
https://github.com/apache/netbeans/issues?q=label%3Acaused-by-plugin+is%3Aclosed
A process to efficiently un-verify plugins is probably at least as
important as having them in the plugin manager in the first place.
(Matthias'es mail admin UI looks great btw! eagerly waiting for the mail
so I can press verify ;))
best regards,
michael
Of course, we could have one catalog and unverify anything that
doesn't work in the current or next release as an alternative? Leaves
anyone sticking with older versions in an awkward position though.
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.
The "downside" (which I still consider the upside given licensing,
etc.) was that it involved external plugin hosting (via GitHub
releases, Maven, etc.) and metadata files in folders containing all
info including file link and hash. Validation would be by PR with CI
verifying and building a static catalog file.
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
