Open Stack

On 06/01/15 03:20, Steve Gordon wrote:
> ----- Original Message -----
>> From: "Maish Saidel-Keesing" <maishsk at maishsk.com>
>> To: openstack-dev at 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-request at 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