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.
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) Vincent 2014-11-05 18:31 GMT+01:00 Kanstantsin Shautsou <[email protected]>: > > > 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]. > 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.
