On Monday 25 January 2016, Nigel Magnay <[email protected]> wrote:
> I am strongly -1 in the idea of forcing plugins to be hosted with > jenkinsci. > > You will already have seen instances where those "granted power" hold an > effective veto over forking plugins into that organisation. > > Well this is a separate issue. I think part of the problem here is that there are 1000+ plugins. More way to do things is not helping users. Some consolidation would be a good thing... But then having said that, if we stop experimentation we cannot let better ways. If the 2.0 update centre has ratings or otherwise provides more of an AppStore like UX then the risk of 20 plugins to have a "sleep N" build step becomes less important... There will be the top rated fart app of Jenkins and others can try to shoot for that crown, but users will pick the best (from the other users PoV) and that makes life better for users... Without that... Well you have name squatting and too many plugins > > That *is* raising a barrier (and one that does not exist if I want to, > for example, publish a maven plugin or a node package). It's contrary to > the notion of an open community, is a retrograde step from the ability to > fork, and inevitably sets us down the "primrose path of open source > governance". Before long you'll be into "all jenkinsci plugins must format > their code *thusly*", or all contributors must sign a CLA, or do CA, or > whatever. > > Maven plugin POMs already contain the SCM location within them. If you're > concerned about end-users finding the source repo, then simply make the > plugin toolchain extract that URL and make it available within the plugins > page. Indeed, since JenkinsCI now has 75 pages of repos - I can no longer > easily find things that I know are there. > > I fail to see what benefit it would bring that could not be achieved in > other ways. > > > > > > > On Mon, Jan 25, 2016 at 10:27 PM, Baptiste Mathus <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi all, >> >> Re-starting this thread because there are still hosted plugins that we >> have sometimes difficulties to find sources for (actual personal experience >> recently on IRC after a user asked where it was), or jenkins_release tweets >> pointing to nothing, and so on. >> And what the project has always been striving for is "making it easier >> for the community". >> >> *So we'd be changing our core principle of low entry barrier?* >> >> No. Having been doing some archeology with *Hosting Request* wiki page >> history, IMO it's actually always, or at least for many a year, been >> considered the standard way. >> Never required per-se, but always assumed (as confirmed by infra team >> member present since the beginning). >> Though indeed, this has been more or less ambiguous or implicit in some >> places I guess. >> Hence this discussion about clarification. >> >> The low barrier entry has always been and still is one of the >> fundamentals of the project. >> And IMO has always been provided through very easy (commit) access & >> hosting. >> >> - For example, if we look at the 2008 version [1] : this is basically >> a HOWTO for the Hudson common svn access. >> - Here in 2010 [2], the code of hosted plugins was assumed to be >> under the Jenkins community infra. >> - In mid 2012 [3], again only the jenkinsci org is listed (svn >> starting to be deprecated). >> >> Historically, IIRC, releasing from 'elsewhere' was technically only >> possible for committers who actually reused their permissions to release >> binaries from elsewhere. >> That would need double-check, but I don't think any (?) new committer was >> ever granted permissions to publish binaries for source code that was not >> planned to be ever hosted under the hudson/jenkins infra. >> >> *So What?* >> >> After having discussed with some here and there, we're considering adding >> that subject to be discussed at the next gov meeting. >> The immediate goal is just to enrich the wiki page(s) so that no more >> ambiguousness/implicitness is left about it. >> >> WDYT? >> >> [1] https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=18808859 >> [2] >> https://jenkins-ci.org/blog/2010/07/28/hosting-your-hudson-plugin-at-github/ >> [3] https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=62063272 >> >> >> 2015-12-01 22:21 GMT+01:00 Christopher Orr <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>>: >> >>> On 01/12/15 16:52, 'Jesse Glick' via Jenkins Developers wrote: >>> > On Tue, Dec 1, 2015 at 5:32 AM, Baptiste Mathus <[email protected] >>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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. >>> >>> 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 >>> >>> -- >>> 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] >>> <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[email protected]');> >>> . >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/565E0F62.605%40orr.me.uk >>> . >>> 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] >> <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[email protected]');> >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7Q1a8OP2N%2BGtNeN6MRhxNSEJPG4osw-0XO8wkf3b2Mnw%40mail.gmail.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7Q1a8OP2N%2BGtNeN6MRhxNSEJPG4osw-0XO8wkf3b2Mnw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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] > <javascript:_e(%7B%7D,'cvml','jenkinsci-dev%[email protected]');> > . > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83QrjKfGBf9hD2VU%3D2SA6c1LUCYOZLMzNPG_ma%2BK8y_wmg%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83QrjKfGBf9hD2VU%3D2SA6c1LUCYOZLMzNPG_ma%2BK8y_wmg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwFN3enRgNAD-52%2BmjV1pjLUy1L7dUhH-6ZA5A-WSFYAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
