Open Stack

On 12/14/2017 3:27 PM, Adrian Turjak wrote:
> 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.

Thanks. Well thought out and well said.

-- 

Thanks,

Matt