Thanks for all the comments. I started responding to comments one by one, but I think it's just going to end up dilluting the conversation, so instead let me explain where I am coming from for one more time, in the hope that it will frame the discussion in the way I want.
A number of you have said they'd rather see bundles plugins reduced or go away entirely. As an eventual solution, no one is arguing against that. I'm just making an observation that that is not a trivial work and it'll take some time to get there. Updating the bundled plugin is a short-term temporary fix until then. When we get to the setup wizard, we can stop bundling plugins, and we are all in the happy state. What I'm trying to do is to buy us some additional cheap "new user happiness" (NUH) until that comes in. IOW, if you think of NUH as a function over time, I'm just trying to lift this function up a little bit over a certain time period until we add the setup wizard. The orange region below. It's a very small effort that buys us some NUH that we can do right now. The question isn't whether the setup wizard is better than what I'm proposing here. Most of us agree on that one. The question is why we shouldn't buy this orange area of NUH. Some people have suggested that we should distribute core w/o plugins or come up with some other means to help people create/share/install a group of plugins. No doubt that's a useful feature, but giving more choice to users does not help NUH. Choosing requires an effort, and we already provide a lot of choices. What we lack is the reasonable combination of plugins we endorse that creates a good first experience, until they get more comfortable with Jenkins and start tinkering with their preferred plugin set on their own. Think of Subway the sandwich shop <http://www.subway.com/>. You can specify exactly what you want down to every ingredient, but most people don't do that because it'll take too much conscious efforts to choose. Instead, we go for one of their pre-built recipes, like Roast Beef sandwich, and we assume they did a reasonable job putting together a reasonable combination that tastes good. I'm just trying to do the same thing here. 2015-08-04 22:56 GMT-07:00 Kohsuke Kawaguchi <k...@kohsuke.org>: > 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 > -- 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/CAN4CQ4xO5gJboAM%2BeO6yHNNyendGBGV1SNoDCz4GnWfoJKC3bA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
