> In this context, I find it quite disturbing that nobody is willing even to discuss an increase of the release cycle from say 2 to 4 years. What is so important about pumping out one version after the other that real issues caused by this speed are ignored? One factor I think is that we’ve seen on multiple occasions that Ceph can have specific toolchain dependencies. This is an observation, not a criticism. Which complicates the competing demands of working on new OS releases — and of working on the OS releases that companies actually run in production. > I think it would make a lot more sense if the observations and discoveries made with production clusters - even or in particular after a long run time on the battle field - were incorporated going much longer back than 4 years. For a system like ceph 4 years is nothing. > > But - and here I come back to my main point - this would require a very scarce resource: time. This is what it all really is about. A slower release cadence would provide time to look into long-term issues and hard challenges with, for example, cache algorithms. There has for a few years been visible advocacy in the software world for CI/CD over “waterfall” releases, with the idea that infrequent releases with large deltas of changes and new functionality are seen as more prone to bugs and regressions than frequent but very incremental releases, as often as monthly, weekly, or even daily. Backports are a double-edged sword. I’ve been there myself, where I yearned for something to be backported (eg. `test-reweight-by-utilization` when I was using RHCS). But if *everything* is backported, does the prior release more or less _become_ the newer release? What’s the “right” middle ground? We might have as many thoughts there as we have subscribers. Here’s an idea for discussion: Might we mull over the idea of switching to a more incremental release cadence, a la Slack or iTerm2? Would that help obviate the current situation where we sort of have three release trains going at any time? I am not advocating for or against this idea, but it would be an interesting discussion. — aad _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |