On 5/29/2015 10:30 AM, Dave Walker wrote:
On 29 May 2015 at 14:41, Thierry Carrez <thie...@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.
A library from an OpenStack POV, from my POV :), is anything that the 'server' projects, e.g. nova, cinder, keystone, glance, etc, depend on. Primarily the oslo libraries, the clients, and everything they depend on.
It's probably easier to think of it as anything in the global-requirements list:
https://github.com/openstack/requirements/blob/master/global-requirements.txt Note that nova, keystone, glance, cinder, etc aren't in that list.
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 __________________________________________________________________________ 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
-- Thanks, Matt Riedemann __________________________________________________________________________ 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
