Open Stack

On 29 May 2015 at 14:41, Thierry Carrez <thierry at openstack.org> 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
>
> --
> Thierry Carrez (ttx)

This is generally my opinion as-well, I always hoped that *every*
commit would be considered a release rather than an arbitrary tagged
date.  This empowers vendors and distributors to create their own
service pack style update on a cadence that suits their requirements
and users, rather than feeling tied to cross-vendor schedule or
feeling bad picking interim commits.

The primary push back on this when we started the stable branches was
a vendor wanting to have known release versions for their customers,
and I don't think we have had comment from that (or all) vendors.  I
hope this is seen as a positive thing, as it really is IMO.

I have a question about still having library releases you mentioned,
as generally - everything in python is a library.  I don't think we
have a definition of what in OpenStack is considered a mere library,
compared to a project that wouldn't have a release.

I also wondered if it might make sense for us to do a better job of
storing metadata of what the shasums of projects used to pass gate for
a given commit - as this might be both useful as a "known good state"
but also, slightly unrelated, might be helpful in debugging gate
blockages in the future.

Thanks

--
Kind Regards,
Dave Walker