-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/01/2015 02:20 AM, Steve Gordon wrote: > ----- Original Message ----- >> From: "Maish Saidel-Keesing" <[email protected]> To: >> [email protected] >> >> 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: >>>> [email protected]?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
I think the section that is really useful is "Known Issues and Limitations". Sometimes it suggests operators to apply some configuration changes to their nodes: https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.2 Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVbBEvAAoJEC5aWaUY1u57PZgIAONnV7PKTF9kCyLZHhC/iOfJ ao1xUrbwK7g6Li5/jha35BijJ0zsR4bFkNknDj8hGf81w0dpUs8A/mndYKsZB9K6 Awv5eho3b7qulO93nkI/JcWlpctGjN7kEAroSFEjDlhbbeiJAvKgTHsmEQy5ilBr 2ymU59LpG/YFWVBsRR1Odm6qBY8+x+YH4vX/GIK1vNy6cvBEqPKHo8dndrvgnHFd fKFoDG6yDyHKv58ZhXsAAB478D4ADtWpI8DjjRpUkkAvX2VPSnY36er6aB5Sh24U wW9l3t1O4S0mJYz5l64D1Qr+EpHugUdOU0jVerDDw+Z6rqlbZvUClW3oY/JH+/o= =hdeZ -----END PGP SIGNATURE----- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
