Open Stack

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