I really doubt that someone new to Jenkins will want to try and use the workflow plugin. Getting a simple Maven or Free Style job setup is enough for most initial users. I would say that intermediate to expert users are the ones that you should be guiding to workflow. Workflow seems to complex for someone new to the whole thing.
On Fri, Aug 14, 2015 at 3:20 PM Kohsuke Kawaguchi <[email protected]> wrote: > I think it's a mistake if we just stop bundling plugins all together > without adding something else to offset the lost new user experience, like > a setup wizard. > > We don't guide users toward plugin manager, and so when the first time > user don't see his SCM of choice in the config UI, it adds to the learning > curve that he has to go to plugin manager. And when you type "git" in there > there are 30+ plugins that show up. > > Git still has one thing going; that is, at least it's very clear what > keyword you need to search. Parameterized trigger plugin and workflow has > this even bigger problem that new users would have no clue that they need > to be looking for them. They have to learn about the existence of that > feature somewhere else first, adding to even bigger learning curve. > > And none of the plugins I'm proposing is a "flavor of the month." Git has > been very popular quite some time, and the parameterized trigger plugin has > a long history. workflow is strategically important for Jenkins. If I start > proposing we change what we bundle every month, that is a problem, but this > is the first time ever I propose this in the 10 years of this project. > > Finally, I know this is not something seasoned Jenkins users will care > about. They know about the plugin manager, they know the "plugin list" Wiki > page, and perhaps they might even know about @jenkins_release > <https://twitter.com/jenkins_release> to learn about new plugins. And for > them, the effort we spend on the setup wizard is an effort we are not > spending on other things they do care. > > But really we are doing this to improve the experience for new users, and > we all need to understand that that is an important thing for the project, > too. > > > 2015-08-05 17:53 GMT-07:00 John Tatum <[email protected]>: > >> 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 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 >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU--e6HMkRVRO3p1MQCCCdFkkrQKeNLD0vbCAv%3D2TU1qjdw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> 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 >> <https://groups.google.com/d/msgid/jenkinsci-dev/BLU179-W79DC5537065F17911647C5F7740%40phx.gbl?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > 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/CAN4CQ4xqEynupsJ94GeHRDhoQc0cgJUhOS4KTgMA3oHxPPSp%3DQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xqEynupsJ94GeHRDhoQc0cgJUhOS4KTgMA3oHxPPSp%3DQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/CAPiUgVd4t2qHvxFAZzrgf7ysPLNezUc9ho2m1nQrPPp93O3dMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
