I agree about this need to remove as such as stuffs as possible by default and to offer in counter part a better classification and organisation of plugins I would like to see a wizard like Intellij Idea has nowadays: * Which SCM will you use ? * Which langages will you use ? * Which build tools will you use ? * .....
On Wed, Aug 5, 2015 at 7:56 AM, Kohsuke Kawaguchi <[email protected]> wrote: > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zHznf-0bTPOgjBv29EFWRbcYTidB7M7uGWgZ4xO-sh9A%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zHznf-0bTPOgjBv29EFWRbcYTidB7M7uGWgZ4xO-sh9A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- ----- Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- 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/CAFNCU--YDEv3VZiQ-pGFwf4UO64wooZAU4%3D%2BFov0U%3D1mZw2o7g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
