On 27.11.24 22:40, Ernie Rael wrote:
On 24/11/27 12:54 PM, Matthias Bläsing wrote:
Am Mittwoch, dem 27.11.2024 um 12:42 -0800 schrieb Ernie Rael:
In this case, "new NetBeans version", what purpose is served by
requiring
authors ... "Request validation"
* Are there many cases where a plugin should/would not be wanted in
the new release?
* Somewhat macabre, what if the author dies?
Why not the supported owner's action is "don't validate" rather than
the
other way around.
Because "Request validation" is an action the author can decide to do
or not do. "don't validate" is not.
They are both actions that can or not be done. I don't get the
"invisible side effect" thing.
It would be an invisible side
effect of creating a new NB version in the portal.
If the author can't be bother to test the plugin,
I wouldn't be surprised if it's common to just click the button
without testing.
it is not fit to be
shipped.
? I could see "appropriate", but seems a broad definition of "fit".
Although I could see how one might assume that click implies support.
Or something.
And if you want it regardless, you can use the catalog für the
previous NB version.
So the user pays if the author's attention is elsewhere.
this is always the case since maintainers are ultimately responsible for
maintaining the software. This does also include to notify their users
(even if it is just via the readme on github) if a project is given up
and/or in search for new maintainers.
It is also standard practice to remove abandonware from "stores". I can
give you an example from an android app where maintenance stopped about
2 years ago and it was removed from both google play and also community
driven "stores" like f-droid.
I do agree that the current process doesn't work that well (for various
reasons which were stated in more detail in past discussions), but I
think there should be some kind of periodic ping from maintainers
indicating that this project is still... well maintained and should be
kept in the catalog.
Is it still an open question of what is the community process that
results in something being taken out of the catalogue? I haven't seen
any discussion on that.
You probably haven't seen discussion about that because I don't think
there was a need to take anything down so far. E.g if something is
causing problems we would file issues against the plugin first - we
never had to escalate so far to remove something I think.
There was one particular plugin which broke file associations even after
it was uninstalled. We had multiple bugs filed against NB because of
this over several releases since it was not obvious from the user
perspective that it was caused by a plugin. (only fix was to reset the
config)
In situations like this, we should be able to temporarily remove plugins
from the catalog. Process for that could be as simple as a quick vote
under PMCs on the dev list or private list dependent on the context.
(but again: this never happened so far AFAIK)
best regards,
michael
Depending on the author to say it works, and not the people that use
it, seems wrong.
If the goal is to optimize workflow... Seems more like there's an
assumption that the click signs a contract that declares the plugin is
fit.
-ernie
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
