On Wednesday, November 5, 2014 8:49:34 PM UTC+3, Vincent Latombe wrote: > > Hello, > > Frankly I'm flattered that you'd want to include a plugin I wrote in core, > but I think the real problem is not really about bundling a plugin in > Jenkins or not. Everyone using Jenkins has different needs, and the fact > that there are so many plugins out there is just a proof of that. > This only proofs that there are many cases and they maybe resolved in different ways: - core, if this belong to core (what criteria?) - new plugin - extend plugin
> > As you said, it is more about the visibility of plugins; essential plugins > getting lost within the thousand plugins that Jenkins now have. There are a > few ideas that could be applied here (ideas taken from app stores) > > - include download stats in the plugin manager and use it to rank plugins > within categories > - introduce a rating system for plugins (also use that to rank plugins) > Let's say "like in Jira". Aaand UI like in jira :) > > > > Vincent > > 2014-11-05 18:31 GMT+01:00 Kanstantsin Shautsou <[email protected] > <javascript:>>: > >> >> >> On Wednesday, November 5, 2014 7:26:25 PM UTC+3, Daniel Beck wrote: >>> >>> >>> On 05.11.2014, at 16:02, Kanstantsin Shautsou <[email protected]> >>> wrote: >>> >>> >> Depends on the kind of job. I'd rather not have builds than run >>> several hours and produce tens of GB of output to run whenever someone >>> checks something in, even though I could. >>> > "This may be the case in your particular company, product, or team, >>> but I really doubt it's universal. " >>> >>> The difference is that I'm not trying to force new UI (that could be >>> done just as well in a plugin) on hundreds of thousands of users because I >>> don't want to install a trivial plugin that would add it to my installs. >> >> Instead of fixing things fundamentally you like having 1k plugins. Ok. >> >> UI buttons from core have been renamed from "Build" to "Build with >> parameters" plus other changes that affected all installations. This >> doesn't provide any improvements for end-users (it added only screwed width >> for the panels). Every release has broken things - it never stopped devs >> from breaking/fixing something. >> >> >>> Given how Jenkins works, it's much easier to add something that's not >>> provided out of the box than to remove something that is, further tipping >>> the scales towards not adding something to core. >>> >>> So the burden is on you to show that it's necessary or useful for a >>> large number users, something you haven't done yet. >>> >>> > This is because people don't know about certain plugins, because >>> jenkins full of useless plugins that hide from eyes good things. >>> >>> This is about interest in the feature, not the plugin. If there were any >>> interest for the feature, there would be >>> >>> - (tens of) thousands of installs of the plugin showing it's widely >>> considered useful, and/or >> >> - feature requests in Jira for a "Poll SCM" link with many votes and >>> watchers >>> >> Votes? Really? Check the most voted issues and when they were created >> https://issues.jenkins-ci.org/secure/Dashboard.jspa?selectPageId=10120 >> (plus some of them closed with comments "reopen for xxx plugin that >> appeared after Y years of initial request"). >> Do you really need votes to update confluence plugin that fixes broken >> links? >> This way doesn't work. As i see i need only 50 votes to get third place, >> do you really want to play with this rating? >> >> Neither seems to be the case. >>> >>> > How much plugins were merged to core in comparison to split? >>> >>> SSH Slaves is the only plugin bundled with core that wasn't bundled due >>> to obvious interest of the project (Translation Assistance) or out of >>> necessity (detached plugins and dependencies of bundled plugins). And that >>> was five years ago. >>> >>> I think the Windows Batch tool installer (the Windows equivalent to the >>> Shell Script tool installer) was available in a plugin before it was in >>> core. There is also an effort to add options from email-ext to the bundled >>> mailer, but I don't know its status. Note that the installer is a generic >>> admin only feature adding no overhead if you don't use it, and the need for >>> fine-grained control over build notification emails is a very common use >>> case as should be obvious from the number of installs of email-ext. >>> >> -- >> 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:>. >> 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.
