On 29/05/15 09:44 -0500, Matt Riedemann wrote:
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-branchTo 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 agree it's not a good point in favor of point releases. If anything, that's just showing some issues with the stable workflow that probably require more attention than the milestone itself.
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.
More than making people focus more on the health of stable branches the whole goal is to remove something that is(?) not necessary. Basically, this proposal removes unnecessary(?) work from stable/release ppl. [snip] Flavio -- @flaper87 Flavio Percoco
pgpAHrGnMKIZ_.pgp
Description: PGP signature
__________________________________________________________________________ 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
