I'm coming back to age old discussions of JENKINS-9598 <https://issues.jenkins-ci.org/browse/JENKINS-9598>.
If you look at the out of the box experience of Jenkins today, it is really dated and not ideal. We have CVS and Subversion bundled out of the box, which is much less commonly used than before. We have some other very commonly used plugins, such as git plugin, parameterized-trigger plugin, envinject plugin, and so on not available out of the box. In addition, the critical new subsystem like workflow plugins are not made available out of the box to users, despite the fact that the industry is shifting from old days of build & test automation to continuous delivery. For many of us in this list who know Jenkins inside out, this is not a problem --- the first thing I do when I start a new Jenkins is to go to plugin manager and install a whole bunch of plugins. How hard can that be, you might ask. But stop for a second and think about the fact that in the past 12 months, we've added more than 30,000 installations. More and more new users are coming to Jenkins. Many of the admins of those 30,000 installations each had to learn what plugins are useful, which of the dozen "git" plugin is necessary, and discover that the workflow plugin is the way forward for writing a complex orchestration. I think we are creating less than steller experience for those users. It creates a wrong perception, and makes the barrier of entry harder. Back then we talked about this (and you can see some comment in JENKINS-9598 as well as the meeting minutes <http://meetings.jenkins-ci.org/jenkins/2013/jenkins.2013-07-10-18.00.log.html#l-6>), we have collectively felt that we don't just keep on adding more bundled plugins, and that the proper solution is to ship a lean jenkins.war that has a better setup wizard like experience, and among other things (such as some initial system config setup of key parameters), it'd help people install the right set of plugins. JENKINS-9598 was filed 4 years ago, and that meeting discussion happened 2 years ago. I think it's safe to say as a community we have failed to address this problem. It is understandable because this is not a pain that many of the core contributors feel (and so we put more weight on downsides like download size increase.) I'm not trying to argue that the consensus built in JENKINS-9598 is wrong, but I feel that we are letting perfect get in the way of better. So this is a proposal to make one time reshuffling of the plugins that Jenkins bundles out of the box. We add the following plugins and their dependencies: - git - parameterized-trigger - workflow Then remove the following plugins: - cvs (split from core in 1.340, 929KB) - ant (split from core in 1.430, 90KB) - maven-plugin (split from core in 1.296, 11MB) This is a first step of improving the out of the box experience, and this journey will include a better setup wizard down the road, at which point we will get rid of the bundled plugins more or less entirely. This change will also not jeopardize the setup wizard change down the road. Unlike those plugins that were split off from the core, plugins that were born outside core can be unbundled any time at a later point without any backward compatibility consequences. The proposed change includes some plugin removals. This has a backward compatibility implication --- when we unbundle plugin that was split from core at 1.X, people upgrading directly from version <1.X will see a loss of functionality until s/he installs the plugin from plugin manager. S/he can avoid this problem by first upgrading to the version of Jenkins that bundles them as a plugin (say current LTS 1.609) instead of going straight to the latest. So the damage is limited. Given that and the fact that 1.430 is released 4 years ago, I think this compatibility implication is very minor that only affects a very small set of people. I've added maven-plugin in the chopping block because it is by far the biggest plugin coming in at 11MB. Some of the concerns people raised in JENKINS-9598 was the increased download size. I'm worried a lot less about it than the out of the box experience, but nonetheless I tried to be considerate for those people. Removing 11MB from jenkins.war would offset the size increase coming from newly bundled plugins. Any objections, thoughts, feedbacks? -- Kohsuke Kawaguchi -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zHznf-0bTPOgjBv29EFWRbcYTidB7M7uGWgZ4xO-sh9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
