[DISCUSS] Hide from the update center plugins without source code under the Jenkinsci github organization?

[Baptiste Mathus]

Hi,

As an aside of Andrew's last e-mail, I'd like to try and clarify what we should do when plugins do *NOT* have their source code under the Jenkins github org:

Should they be visible in the public standard Jenkins update center?

But why care? Because IMO publicly available plugins are a message to users that those plugins are known to the Jenkins org, can be adopted and so on if need be…
A form of trust. Every commits under the org are logged under the irc channel, etc.

But if the code of a public plugin is unavailable, who is responsible? What if a vulnerability is introduced (voluntarily or not) from elsewhere?

Re-reading the "hosting" wiki page, it seems it's been clear about the forking aspect of hosting a new plugin. So plugins not respecting this cannot really pretend that this is new.

Currently I can see those situations:

1. plugins still hosted in svn for historical reasons. In those rare case, I suppose that this could be imported to github anyway. Or deprecated if deemed obsolete.
   
2. plugins forked under the Jenkinsci org, BUT still maintained elsewhere (saw one recently where commits/tags of the last release were NOT in the fork)
   
3. plugins who were never forked but the users released from wherever they want because they have the right Artifactory creds.

IMO, like for the wiki pages, this would be quite a reasonable & small requirement. As a user, I would prefer to know that all the plugins publicly available and installable are hosted and "watched" in the same place.

Others are still free to host a dedicated update center if they wish.

WDYT?

Thanks

-- Baptiste

PS: I kept this mail on the -dev ml for the moment though some of my statements above might be an interesting polls to the users on -users ml: basically are people worried about source code origin/availability for publicly installable plugins.

Le 30 nov. 2015 9:15 PM, "Baptiste Mathus" <bma...@batmat.net> a écrit :

+1. IMO that's really a very small requirement for a plugin author to create his associated page, and as already discussed many times, it's always been one (a requirement).

(Btw: There's also a bunch of plugins who don't even seem to be maintained under the jenkinsci org, I seem to remember we mostly agreed on that also being a requirement too. Gonna create another thread I guess).

2015-11-30 17:16 GMT+01:00 Andrew Bayer <andrew...@gmail.com>:

A surprisingly large number of plugins (35 or so at last check) don't have wiki pages on wiki.jenkins-ci.org, and so don't get populated usefully in the update center. Some of them can probably have wiki pages added by their active maintainers, but others are just...orphaned, for lack of a better term. We'd like to stop manually hacking in pointers to the "Documentation Missing" wiki page for those that still don't have wiki pages in the next month or so, at which point they will stop showing up in the Update Center until they actually have wiki pages again.

You can find the list of plugins we're currently handling manually at https://github.com/jenkinsci/backend-update-center2/blob/master/src/main/resources/wiki-overrides.properties#L70 - these are the ones that would disappear from the Update Center. We've discussed this on https://issues.jenkins-ci.org/browse/INFRA-306 as well.

Thoughts? If I don't hear any strong opposition to this within a week, I'm going to start the clock - four weeks after that, we'll switch the Update Center generation to exclude any plugin without a corresponding wiki page.

A.

--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOZh-gT_bYtkfr36Ay0%3Drv-ZLW%2Bh%2Babd%2Bn6aMNKrRvy2Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

nbsp;!

[Jesse Glick]

On Tue, Dec 1, 2015 at 5:32 AM, Baptiste Mathus <m...@batmat.net> wrote:
> plugins forked under the Jenkinsci org, BUT still maintained elsewhere

There are a number of such cases where the @jenkinsci fork is out of
date. There are even cases where both the original and fork repository
are configured to accept pull requests, which is quite confusing.

Also in some cases the GitHub issue tracker is enabled (inside or
outside @jenkinsci), and there are some issues filed in JIRA too,
which is again confusing.

[Christopher Orr]

I guess being able to make plugin releases (exclusively?) via
Jenkins-on-Jenkins would solve this problem? :)

In any case, it would definitely be good if clicking on "Source code" on
the wiki led to the place where the *most recent release* was made,
rather than pointing to some abandoned fork. Whether that means source
code needs to be exclusively hosted under @jenkinsci, I'm not 100% sure,
but doing so would certainly have a lot of benefits.

Regards,
Chris