On 03/26/2014 03:06 AM, Nigel Magnay wrote:
+1.
I don't like the idea of having some plugins referenced under the
official update center that don't actually come from the jenkinsci
github organization.
The deal seems quite simple to me: either accept to host your plugin
under the jenkins github org, or accept it doesn't appear in the
official/main public plugins list ?
So the cost is that some organisations and individuals may refuse to do
that (for the reasons described), so you get less overall plugins in the
ecosystem. You're not forcing them to assign copyright. You're not
forcing them to use the MIT license. You're not even forcing the plugins
to be open-source. What's the benefit of forcing them to commit to a
particular /organisation/ ? That seems a curiously prescriptive
requirement for a project that in all other ways seems so culturally
'open'. They are, after all, giving this away to you /for free/.
Hmm, perhaps we didn't write it down in [1] because we kinda take it for
granted, but we don't want proprietary plugins in the update center.
As for the reasons behind why we want to force people to a particular
GitHub organization, I already mentioned some of those in my original
response.
To reiterate, one is the continuity. For example, parameterized trigger
plugin was originally developed by Tom Huybrechts, but now it's
maintained by totally different people.
The situation I'm trying to avoid is that with Ant task or Maven plugin,
where there are hundreds of Ant tasks and Maven plugins out there, which
presumably does what the author wanted perfectly, but if someone else
wants to make a little bit of change to make it work for a slightly
different use case, then he'd have to fork it, give it a different GAV
ID, and release it to use it.
Come to think of it, I can think of another example of this. Build
pipeline plugin was a popular plugin originally developed outside our
org, and the development by the original author eventually got stalled,
and the rest of us couldn't carry it forward. It took a conscious effort
to bring it here, which wouldn't have happened for less important plugins.
Another motivation is to use this as an incentive to bring plugin
developers to the community. We get to learn where they are, some of
them will hack on other plugins or core, and it creates one place where
we can run massive "git grep" to find out who is using what extension
points, one place where users can come to file issues, and so on.
Yes, in theory any rules like that discourage some companies and
individuals from participating. But when we look at 906 plugins, I think
it's fair to say we've struck a right balance.
I think there's a secondary benefit /to me/, to being _in the early
days_ outside the jenkins gitub org. When you're mostly noodling around
with a plugin, it's unclear sometimes if the direction is correct, there
may be huge refactorings and change between releases. External
contributions aren't all that useful, because things are moving too
fast. Once it reaches a 'degree of maturity', I'd push it over to the
jenkinsci org - which is my tacit statement of 'seems to be useful /
working to a certian extent -- have at it'. I then /benefit/ because -
anecdotally - you get more contributors that way.
I can see bad scenarios where orgs may end up conforming to the letter
of that rule, but behaving in a way that's inconsistent
with the spirit of what 'having your plugin in the jenkinsci org'
/ought/ to mean (especially in terms of the way it deals with
contributions and commits). This way madness and politics lie.
I believe in the autonomy of people who are doing the actual work, so if
you feel like the plugin is still at the early stage and not ready for
other people to hack on, then I respect that.
But isn't it just a matter of having a README that states so? (And if I
discover that README says "don't hack on this just yet because this is
still very much a work in progress and very fluid" but no commit in the
past 6 months, I'd probably feel comfortable making changes anyway.)
As an aside, It would be nice if Jenkins supported >1 configured plugin
repository. The process of pushing out 'this might fix your issue'
SNAPSHOTS to end-users is pretty tedious, it'd be nice to say 'just
install the latest SNAPSHOT build and see if that works'.
The experimental update center [2] is an effort torward this direction,
and all you have to do to participate is to release with 'alpha' or
'beta' in the version number.
You are right that letting people install bug fixes more quickly is a
good thing. I think a mechanism that lets you click a button in [3] and
install it in your local Jenkins would be nice.
[1] https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document
[2] http://jenkins-ci.org/content/experimental-plugins-update-center
[3] https://jenkins.ci.cloudbees.com/job/plugins
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
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].
For more options, visit https://groups.google.com/d/optout.
