On Tuesday, 1 April 2014, Kohsuke Kawaguchi <[email protected]> wrote:
> 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. This is part of the reason why, for example, CloudBees operate our own update center infrastructure, because we have proprietary plugins and we respect this community so we put our open source plugins in the community organisation and publish those to the community update center. Our closed source plugins go to our own update center(s)... And we have even got one or two open source "meta plugins" that install our update centers in Jenkins (and install the cert to validate our metadata against... the Certs are why it's not just a simple "type in the URL"). - Stephen (wearing his CloudBees hat today) > 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. > -- Sent from my phone -- 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.
