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 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 >> > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier > -- ----- 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--e6HMkRVRO3p1MQCCCdFkkrQKeNLD0vbCAv%3D2TU1qjdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
