On Fri, Oct 2, 2015 at 10:21 PM, Kohsuke Kawaguchi <[email protected]> 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. =) > > 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. A. -- 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/CAPbPdOYZ5%2BLY7TWtzGnCtYWmEoH2oK0fUGgXRGUDKkK-sLO3ig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
