I worry that moving to a yearly release is actually going to make things worse for deployers and there will be less encouragement for them to be on more up to date and bug fixed code. Not to mention, no one will trust or use the intermediary releases unless they are coordinated and tested much like the current release process. That means that anyone is who upgrading faster will be forced to wait for yearly releases because they are the only ones they know to be 'stable'.
I'm actually one of the 20% developers upstream (although I'm trying to change that), and my experience is actually the opposite. I like the shorter release times, I'd find that longer releases will make it much harder and longer waits to get anything in. With the 6 month cadence I know that if I miss a deadline for one release, the next one is around the corner. I've never had issue following up in the next release, and often if a feature or bug fix misses a release, in my experience the core team does a good job of making it a bit more of a priority. With yearly releases I'd be waiting for a year to get my code into a stable coordinated release, and then longer for that code to be deployed as part of an upgrade to a stable release. And I do often miss release deadlines, and that yearly wait would drive me mad. The original goal for our cloud deployment was 1 release behind the latest, or latest if no noticeably conflicting or potentially breaking changes, with our own CI helping us ensure that. We sadly, like most deployers, didn't live up to that goal purely because of what is now a lot of technical debt we are paying off. Now we are paying off that technical debt, and our release/upgrade cadence has improved, and ideally we will get to the point of running latest releases again. As a developer who does a bit of operations, I don't like the idea of yearly releases because it means that those are my only safe option to upgrade to, when in truth getting stability and bug fixes in sooner (or at least potentially sooner) is where we want to be. Yes we can use master but using master requires a lot of per project knowledge as to what is being merged in at that time and what specs are being worked on, because, as well as we all try to keep master stable, in introducing larger changes there are always times when a few little things aren't quite right until all the related reviews for a given feature of bug are merged. Tagged milestones work, but the safety of a coordinated release is still much better and requires less potential pain. We are also one of those weird deployers that at times runs wildly different versions of the various openstack components, with a large amount of our own testing to help us ensure our cloud still operates smoothly. We like smaller releases, because it lets us do incremental upgrades to services with less features or changes, and helps us ensure that no major version imbalance will cause any breaks. Larger yearly releases gives us far less choices in the matter, and could in fact potentially make this harder. My other worry is that this proposal still feels related to the LTS problem because it forces the community to now ensure safe upgrades between much larger yearly releases. Effectively this forces us to now support skip releases for 1 release back, while calling it something else. It puts a larger burden on everyone as well since the releases are much bigger (more changes to read through and compare), and more likely to break during upgrade, thus likely making most deployers less likely to upgrade until others have potentially fixed the pain or written up how to avoid it thus pushing them even further behind. I may be reading into this a little, but this proposal in a large part feels like a push towards something closer to what LTS maintainers want releases to look like, rather than what might be good for everyone else. The other thing I really don't like is community goals being set once a year. Some may be done faster than others, and we may want to introduce new ones partway through the year. It assumes on a project as big and complex as openstack we can alway see a full year ahead in perfect clarity. I don't even think goals should have to always be bound to one release as it is. Thierry himself said: "having one full year to complete those will let us tackle more ambitious goals", which makes me wonder, why can't we now set a goal that covers two releases, with its intended end target being the following release, and set tasks that need to completed in the first release of the two? This does not require a yearly release, and while I get that single release goals will get more priority, that's mostly a problem of management which will exist in yearly releases (and goals) anyway. If another part of the goal here is to lower overheads and management effort, then PTLs can hold office for two releases, we can drop the summit to once a year, etc. These things do not need to be bound to the release cadence. TLDR: -1 I don't like yearly releases. Longer for developers to land features if they miss a release deadline, less choice for deployers, longer between official bug fixed releases, makes already large releases bigger and more dangerous, and feels like it is trying to solve unrelated problems. On 15/12/17 04:16, Dan Smith wrote: > Ed Leafe <e...@leafe.com> writes: > >> I think you're missing the reality that intermediate releases have >> about zero uptake in the real world. We have had milestone releases of >> Nova for years, but I challenge you to find me one non-trivial >> deployment that uses one of them. To my knowledge, based on user >> surveys, it is only the major 6-month named releases that are >> deployed, and even then, some time after their release. >> >> Integrated releases make sense for deployers. What does it mean if >> Nova has some new stuff, but it requires a new release from Cinder in >> order to use it, and Cinder hasn't yet released the necessary updates? >> Talking about releasing projects on a monthly-tagged basis just dumps >> the problem of determining what works with the rest of the codebase >> onto the deployers. > Similarly, right now we have easy and uniform points at which we have to > make upgrade and compatibility guarantees. Presumably in such a new > world order, a project would not be allowed to drop compatibility in an > intermediate release, which means we're all being forced into a longer > support envelope for versioned APIs, config files, etc. > > If we did do more of what I assume Doug is suggesting, which is just tag > monthly and let the projects decide what to do with upgrades, then we > end up with a massively more complex problem (for our own CI, as well as > for operators) of mapping out where compatibility begins and ends > per-project, instead of at least all aiming for the same point in the > timeline. > > --Dan > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev