+1 Where should it be listed? The plugin's wiki page? Lack of this "badge"
precludes certain plugins from being used. This will adversely affect
"maintenance only" plugins, or orphaned plugins.
On Tuesday, March 3, 2015 11:32 PM, Daniel Beck <[email protected]> wrote:
On 04.03.2015, at 08:09, domi <[email protected]> wrote:
> btw. we should have a checklist which talks about a minimal set of rules a
> new plugin should follow before we allow it to be forked. Other things I
> would like to see there are:
> - clear documentation
> - the <url>-tag in the pom.xml points to an existing page
>
> WDYT?
We talked about something similar a while back in the governance meeting (Oct 1
and 15 2014). There are numerous plugins that:
- Don't track their issues in our Jira and possibly not even in @jenkinsci
- Don't have a wiki page in our Confluence and/or don't link there (and
possibly link nowhere)
- Don't host their source code and/or release tags in Jenkins SVN or the
jenkinsci Github org
- Don't provide their sources or have non-public source repositories
IMO plugins that get distributed using the the Jenkins update center should do
all of these or be kicked out to allow for a consistent user (and developer)
experience. Basically, write whatever plugin you want, but if you want
distribution to every Jenkins out of the box, you need to follow some rules.
These particular rules should also be fairly easy to check for. We could also
add an option to Jenkins to allow users the choice whether they want to get
offered noncompliant plugins, similar to the 'experimental update center'
option.
Going a step further and also requiring some best practices in the
implementation could be done as well, but we need to be careful about what we
want to enforce and balance necessary restrictions with giving plugin authors
freedom in what and how they contribute. Then there's the problem with existing
plugins that may even predate credentials -- how to treat them? Just checking
on fork seems not enough to me.
Another option would be to improve plugin manager to make it more like an app
store. This would allow for badges, tags, or 'list of plugins that do X',
indicating plugins that adhere to certain best practices. "Designed for secured
Jenkins" comes to mind as well -- some plugins have scripting options and just
don't care who gets to run arbitrary code.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/0F11F6CB-CFDA-42C5-B753-30CDE4C97054%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/730039146.2803208.1425493103045.JavaMail.yahoo%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.
