As I look over this thread, there does seem to be consensus that if we were to change the Jenkins plugin bundle at all, we would want to effectively remove them all from being installed. We would want to empty that set of bundled plugins not just because the distribution download size might get smaller, but more importantly, because the bundled set is immediately installed, difficult to fully remove, and given special status through version upgrades. Also, pinning is weird.
....that seems like a consensus view, IMO. That the primary Jenkins distribution should be completely barebones and neither come with any suggestion of what plugins to install nor a quick and flexible way to choose and install them does not seem like a consensus. Rafael's somewhat circumspect position of wanting a recommended list or lists, but not wanting that list forced on him seems closer to the consensus. Stephen Connolly then offers a sketch of how these recommended plugin sets could come to life, and that also seems to be close to consensus. For argument's sake, let's say we were to do the Rafael/Connolly solution and allow 3rd parties to easily create plugin sets. How would we advertise those plugin sets? How would a new user know they exist? Would there be something in the core Jenkins that would let new users know that these sets were available? (...I mean these as real questions, not gotcha statements...) ...these questions are particularly important if the point of one or more of these sets is meant to facilitate new users getting started with Jenkins. On Sunday, August 23, 2015 at 6:42:23 AM UTC-7, Kanstantsin Shautsou wrote: > > When you are installing any linux distro, you has ability to choose > software and it also requires restart. Gradle also has no default plugins > enabled. If you want suggest somebody the number of plugins that is good by > default for you, then make docker image and share (how Stephen proposed). > You can, also, rebundle in your enterprise jenkins anything you want. But, > please, don't pollute FOSS jenkins. This thread contains enough feedback > from people that really using Jenkins (and not managers) to close this > topic, and even more - how increase first usage experience in other ways. > > This topic was also rejected by governance meeting. > > Sent from my iPad > > On Aug 23, 2015, at 12:44 PM, Sacha Labourey <[email protected] > <javascript:>> wrote: > > Hello Daniel, > > > On Sun, Aug 23, 2015 at 12:44 AM, Daniel Beck <[email protected] > <javascript:>> wrote: > >> On 22.08.2015, at 15:40, Sacha Labourey <[email protected] >> <javascript:>> wrote: >> >> > My perception from this discussion is that we are aiming for the exact >> opposite i.e. slick and virgin for everybody and hope new users will be >> able to magically decide what a good average getting started experience >> might be, this is likely to only satisfy the advanced users. >> >> The 'slick and virgin' part could be achieved by only using bundled >> plugins for functionality extracted/detached from core, and not installing >> them on a new system. Many of the bundled plugins aren't even popular, and >> almost all of them are really only bundled to not break upgrades, so making >> them the default set of features for Jenkins doesn't really make sense. >> >> On a new installation (that would otherwise lack a lot of fairly >> essential features, such as at least one SCM implementation), a setup >> dialog of some kind could enable new users to quickly get started. Advanced >> users could skip right past that and use the plugin manager to install what >> they need. The responses by Kostya, Vincent, Oliver, and Tom seem to aim >> towards something like this. I suggested basically this last year in >> JENKINS-9598. >> > > I understand this, but it forces new users to make a choice, when they are > likely not equipped to make a choice. So we are forcing a first download, a > choice, followed by another download (based on the choice she made), and > possibly a restart. That is convoluted to me. > > >> >> > my iPhone came with pre-installed applications >> >> Illustrates one of the arguments against bundling plugins well: These >> apps cannot be deleted either if you're not using them. A different way of >> 'bundling' plugins that would only actually install them when needed to not >> break the instance on upgrade (and allow deleting the plugin), would >> complement a 'plugin setup' of some kind well. >> > > Well, you are taking an iOS specific choice (not able to uninstall) to > simplify the argument but that's not my point :) My point is that my dad > and countless people sure enjoy receiving a phone that just works for the > average use. He might not use the Passbook app, for sure, he might need > other apps, for sure, but the default setup and user experience was great > and made it possible for him to discover more, and become opinionated over > time about what he wanted vs. not. Here, we are asking people to be > opinionated as they do a first install. Live if upon booting iOS, it would > simply start the App Store and tell you "well, just build the specific > iPhone that matches your need, it does nothing for now." > > >> >> AFAICT I don't think you're disagreeing with most responses here -- it's >> just that the specific approach of bundling a plugin (nobody can opt out) >> is undesirable, and an alternative approach that would benefit both new >> users and experienced users would be much preferred. >> > > Forcing a two-steps download process is very very odd to me, it makes for > a horrible user experience. If you want to offer a jenkins-core download > for hardcore user, I think it is great, but it doesn't feel like it should > be the default. > > >> >> > • Provide a default user experience with pre-loaded/packaged plugins >> that satisfy even 50% of the users (guide them, show them a good/typical >> way) >> > • Let them customize this base easily (this is where the current >> proposal of bundle of plugins, etc. is good IMO) >> >> The first could be achieved through the second with an option to install >> a recommended set of plugins suitable for most (new) users. Don't know know >> what you want because you're new? 'Install Recommended Plugins' (and maybe >> select which SCM) and done. >> >> Right, two steps :) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/kRobm-cxFw8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAFgqX_PB-v4kHOw474D9nSiD3jyPnrLpY-2scusEKNy48enTjA%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CAFgqX_PB-v4kHOw474D9nSiD3jyPnrLpY-2scusEKNy48enTjA%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/7eacc40d-f0ca-4fed-a80f-38a3dc71c7d1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
