Open Stack

----- 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