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]> 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]. > 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/CAOcHHXzFTqgWx-d%2B7u%3Dq2rDgcGOdL6D6kRY5ASn%2BbYyU9B1E%3Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
