Open Stack

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 <ed at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev