> 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@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
