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 <kanstantsin....@gmail.com>: > > > On Wednesday, November 5, 2014 7:26:25 PM UTC+3, Daniel Beck wrote: >> >> >> On 05.11.2014, at 16:02, Kanstantsin Shautsou <kanstan...@gmail.com> >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. > 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 jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
