> > So James, are you then arguing that we should leave the existing plugin > bundle alone?
Hell no :) ...or are you just saying a remote connection for initial plugin collecting > is problematic? > This *could *be problematic for a certain type of users who are not experienced jenkins admins and that the current proposal will mean that if they installed fresh today they could at least play with Jenkins, whereas in a years time they would not be able to play with jenkins (no Job types!) and then they could just walk away after the initial download. There are multiple ways to solve this issue - but if we are no longer bundling anything then I think when that is switched on we need something that can get a simple system up for a newbie in a restrictive environment. I've mentioned the eclipse bundles, theres downloading a zips by selection of multiple plugins, or you could embed the version of the metadata that the new wizard uses in the war at build time, and this could be used to generate a shell/bash script that sucks down those exact files on a different system... There is plenty more possibilities for solutions, I just think we need to have one in place such that if there is no internet access we can provide at least some instructions to a new user in order to help them get up and running and evaluate Jenkins (after all - its that first impression that counts!) On Tuesday, September 1, 2015 at 6:53:33 PM UTC+1, Gus Reiber wrote: > > So James, are you then arguing that we should leave the existing plugin > bundle alone? > ...or are you just saying a remote connection for initial plugin > collecting is problematic? > > On Tue, Sep 1, 2015 at 9:30 AM, James Nord <[email protected] > <javascript:>> wrote: > >> Daniel, >> >> So while these are all relevant points, it's a completely different >>> issue, only affecting very experienced users in an unusually restrictive >>> environment only. Everyone else just uses the update center. >>> >> >> You responded to this when it was explicitly about restrictive >> environments. >> >> 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 >> >> >> So to say deploying plugins one by one has a workaround - when the >> workaround will not work in the environment described doesn't a workaround >> make. >> >> So while these are all relevant points, it's a completely different issue >>> >> >> Fair enough - but you [cs]hould have said that earlier. >> >> only affecting very experienced users >>> >> >> I disagree with that. There is no correlation between the security >> paranoid companies/governments and the experience of the Jenkins user. >> Infact you may well find that in restrictive sites you are more likely to >> get noobies as the install may have to be provided by the IT department who >> are not developers and have not even seen the UI before. >> >> So this bare-bones jenkins won't do anything for new users - which is a >> bit of a concern - not even build a job when freestyle gets pulled out of >> core, and that to me really kind of sucks and leaves a user feeling like >> the tool is broken - rather than they need to do something. So that I feel >> would be a mistake of epic proportion. >> >> A long long time ago I was setting up cruise control, I wasted an awful >> amount of time over the period of a week and I just couldn't get it to work >> with my subversion repo and my build tooling. I then downloaded Jenkins >> and was running in less than one hour. Why am I telling you this - >> because that first impression is golden. If you remove a %age of users >> that can't access the update center to get even the simple FreeStyleJob >> then we are the new cruise control. Do I have a solution - Yes/No/Maybe... >> Eclipse.org provides "distributions" you can get the basic IDE and add >> the plugins you want - or you can get the Java version, or the J2EE >> version, or the PHP version... If we have something that has no >> functionality out of the box - I think we need somthing that also comes >> with some functionlity in the box - you can still show the wizzard to >> customize (if you have a internet connection) but if you don;t you have >> something you can at least experiment with. >> >> >> On Monday, August 31, 2015 at 6:04:32 PM UTC+1, Daniel Beck wrote: >>> >>> >>> On 29.08.2015, at 10:46, James Nord <[email protected]> wrote: >>> >>> > That should work, but I don't see how that would work with mirroring. >>> I would rather see something generate a zip containing the plugins and deps >>> being generated that you can upload in one rather than generating new wars, >>> otherwise the poor people that use the native packages will be out in the >>> cold. >>> > Also need to consider security in this as you know what you get from >>> the update center is the correct binary... >>> >>> The idea here is to make it easier for new users to get started with >>> useful functionality. Right now we bundle a bunch of irrelevant features >>> (e.g. Monitor External Job) and are missing a lot of popular and -- by >>> today's standard -- essential features. (A nice side effect is to get rid >>> of the annoying parts of 'bundling', like no uninstall.) >>> >>> So while these are all relevant points, it's a completely different >>> issue, only affecting very experienced users in an unusually restrictive >>> environment only. Everyone else just uses the update center. >>> >>> -- >> 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/92cc1041-695e-4d3c-ae6d-cd53c782dedf%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/92cc1041-695e-4d3c-ae6d-cd53c782dedf%40googlegroups.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/bd7825cc-4daf-49f4-b569-1dc5a7cdbbc6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
