Open Stack

On 5/29/2015 8:41 AM, Thierry Carrez wrote:
> Hi everyone,
>
> TL;DR:
> - We propose to stop tagging coordinated point releases (like 2015.1.1)
> - We continue maintaining stable branches as a trusted source of stable
> updates for all projects though
>
> Long version:
>
> At the "stable branch" session in Vancouver we discussed recent
> evolutions in the stable team processes and how to further adapt the
> work of the team in a "big tent" world.
>
> One of the key questions there was whether we should continue doing
> stable point releases. Those were basically tags with the same version
> number ("2015.1.1") that we would periodically push to the stable
> branches for all projects.
>
> Those create three problems.
>
> (1) Projects do not all follow the same versioning, so some projects
> (like Swift) were not part of the "stable point releases". More and more
> projects are considering issuing intermediary releases (like Swift
> does), like Ironic. That would result in a variety of version numbers,
> and ultimately less and less projects being able to have a common
> "2015.1.1"-like version.
>
> (2) Producing those costs a non-trivial amount of effort on a very small
> team of volunteers, especially with projects caring about stable
> branches in various amounts. We were constantly missing the
> pre-announced dates on those ones. Looks like that effort could be
> better spent improving the stable branches themselves and keeping them
> working.
>
> (3) The resulting "stable point releases" are mostly useless. Stable
> branches are supposed to be always usable, and the "released" version
> did not undergo significantly more testing. Issuing them actually
> discourages people from taking whatever point in stable branches makes
> the most sense for them, testing and deploying that.
>
> The suggestion we made during that session (and which was approved by
> the session participants) is therefore to just get rid of the "stable
> point release" concept altogether for non-libraries. That said:
>
> - we'd still do individual point releases for libraries (for critical
> bugs and security issues), so that you can still depend on a specific
> version there
>
> - we'd still very much maintain stable branches (and actually focus our
> efforts on that work) to ensure they are a continuous source of safe
> upgrades for users of a given series
>
> Now we realize that the cross-section of our community which was present
> in that session might not fully represent the consumers of those
> artifacts, which is why we expand the discussion on this mailing-list
> (and soon on the operators ML).
>
> If you were a consumer of those and will miss them, please explain why.
> In particular, please let us know how consuming that version (which was
> only made available every n months) is significantly better than picking
> your preferred time and get all the current stable branch HEADs at that
> time.
>
> Thanks in advance for your feedback,
>
> [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
>

To reiterate what I said in the session, for my team personally (IBM), 
we don't align with the point release schedules on stable anyway, we 
release our own stable release fix packs as needed on our own schedules, 
so in that regard I don't see a point in the stable point releases - 
especially since most of the time I don't know when those are going to 
be anyway so we can't plan for them accurately.

Having said that, what I mentioned in IRC the other day is the one 
upside I see to the point releases is it is a milestone that requires 
focus from the stable maintainers, which means if stable has been broken 
for a few weeks and no one has really noticed, converging on a stable 
point release at least forces attention there.

I don't think that is a very good argument for keeping stable point 
releases though, since as you said we don't do any additional testing 
above and beyond what normally happens in the Jenkins runs.  Some of the 
distributions might have extra regression testing scenarios, I'm not 
sure, but no one really spoke to that in the session from the distros 
that were present - I assume they do, but they can do that on their own 
schedule anyway IMO.

I am a bit cynical about thinking that dropping point releases will make 
people spend more time on caring about the health of the stable branches 
(persistent gate failures) or stale changes out for review.  I combed 
through a lot of open stable/icehouse changes yesterday and there were 
many that should have been abandoned 6 months ago but were just sitting 
there, and others that were good fixes to have and should have been 
merged by now.

Personally I've been trying to point out some of these in the 
#openstack-stable IRC channel when I see them so that we don't wait so 
long on these that they fall into a stable support phase where we don't 
think they are appropriate for merging anymore, but if we had acted 
sooner they'd be in.

But I'm also the new guy on the team so I've got belly fire, feel free 
to tell me to shut up. :)

-- 

Thanks,

Matt Riedemann