On 22/10/22 5:09 AM, Michael Bien wrote:
On 21.10.22 14:24, Neil C Smith wrote:
On Fri, 21 Oct 2022 at 12:43, Michael Bien <mbie...@gmail.com> 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)
An alternate approach to handling unverified plugins is to allow
download from the plugin page, and the user manually installs it. I was
(and still am) surprised that a plugin can not be fetched via the plugin
portal, a lost feature from the pre-apache days. A plugin could have
status like, for example:
1. Verified
2. pending verification
3. unverified
4. failed verification
5. blocked
I suppose there's a matrix of NB-version vs Plugin-version vs status
(displayed simply in a understandable fashion). I guess only "Verified"
would show up in the plugin update center in running NetBeans. Allow
manual download/install from the portal for 2, 3, maybe even 4? Maybe
there's something between 3,4 like user reported failures, but that
seems a slippery slope?
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. '
Verification delays is the reason I publish a plugin portal. If there's
a bug, I want to make the fix available as soon as possible. I'd like to
have the implicit versioning that's provided by a catalog per NB version
(the new scheme we're struggling to get to), but plugin reliability is
more important. So the plugin jumps through hoops so the same bits can
run on multiple NB versions (not sure I'd stop doing that, there are
advantages to having one plugin version for many releases)
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.
And some process that too many "caused-by-plugin" has an effect on the
plugin's status at the plugin portal.
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: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
