On 06/01/15 03:20, Steve Gordon wrote:
----- Original Message -----
From: "Maish Saidel-Keesing" <mais...@maishsk.com>
To: openstack-dev@lists.openstack.org
On 05/29/15 18:25, Matthew Thode wrote:
On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
What about release notes? How can we now communicate some changes that
require operator consideration or action?
Ihar
On 05/29/2015 03:41 PM, 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
__________________________________________________________________________
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
for release notes just do git log between commit hashes?
Do you really think that is what an Operator will do? I do not think is
a realistic expectation or something that will work.
--
Best Regards,
Maish Saidel-Keesing
While I agree most operators probably don't want to necessarily dig this out of git
themselves and it would need to be collated/exposed in a nicer way it seems like it would
actually be more accurate than the current "release notes" for all the
non-security bug fixes in stable which basically amount to a list of launchpad bug
queries per project. You then have to sift through each bug to work out if the
description reflects what was actually done etc:
https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3
-Steve
I agree - and if this could be automated in some way to make is
presentable - that would be ideal
--
Best Regards,
Maish Saidel-Keesing
__________________________________________________________________________
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
