One of my sore points with Jenkins has always been the included plugins. Personally, I would rather see nothing included. The whole point of plugins is to have a modular system, so including things out of the box just ends up being more stuff users have to get rid of on a clean install because they do not use/need/want it.
I am all for stripping plugins out, but I think including plugins is going the wrong direction. This is especially true for things like build tools and SCM clients because in many cases there is additional software that needs to be installed on the system for the plugin to be useful. It makes no sense to me to include a plugin that will not work out of the box. My next point against including plugins is that basing what plugins are included on the flavor of the month (in terms of the tools available) inherently means that the Jenkins project would be following trends and fads in development. What happens when NewSCM is just as popular as Git? Do we now include two plugins out of the box? It also means assumptions about how users are handling the FotM. For example, many Git hosts and servers provide a Subversion bridge, so just because somebody is using Git for SCM does not mean they are using the Git client. I will second Arnaud's assessment of pinned plugins. I think they are useful to somebody who understands them(under the right circumstances), but that is offset by being entirely unintuitive. In my opinion, Jenkins should be as un-opinionated and tool agnostic as possible. In my experience, this is the source of a great deal of Jenkins' appeal. As far as a wizard goes, I do not know how useful it would really be. There are some config/settings changes (ie, workspace location, listening port, the option to configure some security settings) that would be convenient to be made through a wizard, but I do not think there are enough to justify it. IMO, Jenkins is very user friendly. Are there things that could be improved? Absolutely, but at the end of the day I can think of quite a few things that are far more important to me, as a user, than what plugins are bundled with the .war. John Tatum [email protected] http://scientifichooliganism.net Although this e-mail and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and/or upon which it is opened, it is the responsibility of the recipient(s) to ensure that it is virus and/or defect free and John Tatum bears no responsibility for any loss and/or damage arising in any way from its use. From: [email protected] Date: Wed, 5 Aug 2015 22:53:33 +0200 Subject: Re: Revisiting bundled plugins To: [email protected] And if it is for next Xmas: Don't forget all users who are deploying Jenkins in a environment with no internet (or a limited access). Thus if we could pack together some set of plugins (and required dependencies) and allow jenkins to "eat" them. Deploying plugins one by one is a nightmare and error prone On Wed, Aug 5, 2015 at 10:51 PM, Arnaud Héritier <[email protected]> wrote: Ohhhh and I forgot a point: Let's fix the nightmare created by pinned plugins at the same time.It is a concept really difficult to understand for users. On Wed, Aug 5, 2015 at 10:49 PM, Arnaud Héritier <[email protected]> wrote: 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 pluginsI 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. 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), 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:gitparameterized-triggerworkflowThen 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. For more options, visit https://groups.google.com/d/optout. -- -----Arnaud Héritierhttp://aheritier.netMail/GTalk: aheritier AT gmail DOT comTwitter/Skype : aheritier -- -----Arnaud Héritierhttp://aheritier.netMail/GTalk: aheritier AT gmail DOT comTwitter/Skype : aheritier -- -----Arnaud Héritierhttp://aheritier.netMail/GTalk: aheritier AT gmail DOT comTwitter/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--e6HMkRVRO3p1MQCCCdFkkrQKeNLD0vbCAv%3D2TU1qjdw%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/BLU179-W79DC5537065F17911647C5F7740%40phx.gbl. For more options, visit https://groups.google.com/d/optout.
