Hmmm, you mentioned it's "It's kind of a problem that we have "ci" baked into our domain name". However obviously both Travis CI and Circle CI (and maybe others?) use the term "CI" in their titles and domains, but that hasn't stopped them from including great support for continuous deployment in their products.
I've never known anyone to not choose Jenkins just because they thought it was limited to CI. With that said, I do agree that the Jenkins website could describe the product better and it'd be a good idea to include the the term continuous deployment there. Two cents. On Friday, October 2, 2015 at 4:21:57 PM UTC-4, Kohsuke Kawaguchi wrote: > > > > 2015-10-01 2:23 GMT-07:00 Andrew Bayer <andrew...@gmail.com <javascript:>> > : > >> Some thoughts... >> >> jenkins.cd is a bad idea. It has a weird feel to it - I've never seen >> another .cd domain. It's more narrow and marketing-specific than >> jenkins-ci.org, as has been said. Honestly, it feels more like a startup >> domain than an OSS project domain. If we can get jenkins.org or another >> of the more common TLDs, sure, that's an improvement, but jenkins.cd >> just doesn't feel right. >> > > 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 not comfortable with the timeframe - this is our best opportunity to >> make major architectural changes to core for a long time, and we should >> really take advantage of that. Let's have real discussions about breaking >> compatibility in some places, re-doing the backend storage (I strongly feel >> we should move core's storage (and quasi-core plugins like junit-plugin, >> Maven/matrix job types, etc) to an abstraction layer - so that it becomes >> possible to move builds/tests/etc to be stored in something other than >> XML), etc. >> > > I assume you mean storing XML in something other than a file system. > > Given that I think 2.0 should be more radical a change than proposed, I >> also think we should keep the 1.x LTS line going for like a year - just bug >> fixes, of course, but we'd really need to have a path for people to take >> time to move off of removed functionality or plugins that won't work any >> more in 2.0, etc, and keeping up the LTS track is a necessary part of that. >> > > 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 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. > > 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. > > > A. >> >> On Thu, Oct 1, 2015 at 12:31 AM, James Nord <james...@gmail.com >> <javascript:>> wrote: >> >>> OT: if you can buy some ssd disks and raid them so you can get space and >>> redundancy you will probalg see an order of magnitude difference. I had >>> start up times of 3 hours which fell to 3 minutes... As for tests have >>> you tuned the jvm memory settings? If not then the results get garbage >>> collected whilst loading other results that are needed which keads to the >>> results being loaded again which leads to.... And eventually enough loads >>> and gcs pass that it works again. >>> Apart from artifact/log archival/retreival most of the io in jenkins >>> will be loading small files and random Iops is king not sequential >>> bandwidth. YMMV standard disclaimers apply >>> >>> -- >>> 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-de...@googlegroups.com <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/7f434dd9-a7c6-4477-ac46-43bf34dbb8b4%40googlegroups.com >>> . >>> 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 jenkinsci-de...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYtrnhrkZORCTzGxgRrMhydS%3DzEKRAS8FffPaK_24Ln2A%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPbPdOYtrnhrkZORCTzGxgRrMhydS%3DzEKRAS8FffPaK_24Ln2A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kohsuke Kawaguchi > -- 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/fee104c0-7088-48df-a87b-fb2f920fb01b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
