I agree with Kohsuke. What would happen if the the original writer of a non-hosted plugin stops supporting it? Somebody would probably end up forking it (if it's on Github) and might even host it in the jenkins organisation. It's kind of unclear what would happen in such scenario.
A pragmatic approach would be for Jenkins to support the visualisation of the originating company name/logo in the plugin manager. That would give big visibility to companies that embrace open-source and contribute plugins to the Jenkins ecosystem. Emanuele Zattin --------------------------------------------------- -I don't have to know an answer. I don't feel frightened by not knowing things; by being lost in a mysterious universe without any purpose -- which is the way it really is, as far as I can tell, possibly. It doesn't frighten me.- Richard Feynman On Wed, Mar 26, 2014 at 11:06 AM, Nigel Magnay <[email protected]>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*. > > 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. > > 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'. > > > > -- > 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. > -- 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.
