+ Folders Plugin is good candidate as grouping entity for jobs hierarchy. On Wednesday, August 5, 2015 at 10:28:07 PM UTC+3, Kanstantsin Shautsou wrote: > > Many times before some starting guide was discussed. IMHO better create > starter-plugin that will provide some groups of plugins as Java/PHP/etc > packs so user can easily choose what install. > Or probably provide predefined sections like SCM that will dynamically > provide i.e. 3 top installed scm plugins (i guess it will be git, > subversion) for installation, 4 flow plugins (and here workflow will > appear) and etc. for fast installation. > IMHO it more safe to bundle button plugins that provides buttons for core > functionality that wasn't implemented and not accepted into core code like > PollSCM, SafeRestart and etc. > > I don't think that core needs ship any bundled plugins, especially > workflow that is not stable and has no UI for end-users. > Also less plugins less core size that is good for container images and > jenkins stability. > > On Wednesday, August 5, 2015 at 8:57:04 AM UTC+3, Kohsuke Kawaguchi 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/e2ad0e0b-05c2-478b-b2d1-44660a6e4760%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
