2015-10-05 12:10 GMT+02:00 Andrew Bayer <andrew.ba...@gmail.com>: > On Fri, Oct 2, 2015 at 10:21 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote: > >> >> I don't want to get into the CI vs CD definition argument, but I think CD >> is less narrow than CI. >> >> Initially I wasn't very keen on the new domain name myself, but over the >> time it growed on me and I started seeing the point of it. Name is >> important, and domain name is one of the first things that people see. >> > > I'm still not persuaded. =) >
Personally still trying to decide if it's visionnary or weird ;-). But indeed, jenkins.cd is also growing on me. Maybe others system will just follow The Jenkins Way like they all struggle to do currently ;-). > >> >> I assume you mean storing XML in something other than a file system. >> > > Or theoretically serializing to something other than XML - that'd be > tougher, obviously, but not *much* harder. > > >> >> I just don't see how this can work out. A fundamentally incompatible 2.0 >> that takes a lot longer to do, which breaks massive number of plugins. And >> then we let those people stay on Jenkins 1.x longer. It's going to >> significantly delay the launch of 2.0, then delays the migration further >> out. >> > > I'm not advocating incompatibility for the sake of incompatibility - just > saying that this is our opportunity to make significant architectural > changes, so we should at least consider them. > > >> >> I'm not saying storage pluggability is a bad idea, it's the opposite. >> It's just that with all things considered, I don't think it's the best move >> to spend our precious resources on it at the moment. As I wrote, this is >> trying to cater to people who are newly coming to Jenkins, which is big in >> numbers. And for those who are running huge deployments, what >> eBay/Paypal/CloudBees/etc are doing --- lots of small masters in an elastic >> environment instead of one giant monolithic master --- makes a lot of >> sense, and addresses # of other related problems that those guys face. >> > > Yeah. A bunch of things are just not really viable with the current > storage - HA most notably, etc. > > >> But you aren't the first one to point out about the storage pluggability. >> So maybe there's some version of it that can be done reasonably that's also >> compatible over time. That is, we could still require one directory per >> build, but at least store build records and job configurations elsewhere to >> help startup time and build history traversal. Kind of like what DotCi does. >> > > Yeah, that's pretty much exactly what I'm hoping for. > Makes me thing about https://www.cloudbees.com/jenkins/juc-2015/presentations/JUC-2015-USWest-Scaling-Jenkins-Dayal.pdf I've read this morning. 2.0 may also be the right time to try and incorporate some of that Google's feedback. -- Baptiste -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS51OoawYaUZAhWX_tTOxcunJW%3D%2Bfh0uxjPd5LyRudUEeg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
