Open Stack

On 21 August 2015 at 11:38, Thierry Carrez <thierry at openstack.org> wrote:
<SNIP>
> Since then, replying to another concern about common downstream
> reference points, we moved to "tagging everything", then replying to
> Clark's pollution remark, to "tag from time to time". That doesn't
> remove the need to *conveniently* ship the best release notes we can
> with every commit. Including them in every code tarball (and relying on
> well-known python sdist commands to generate them for those consuming
> the git tree directly) sounded like the most accessible way to do it,
> which the related thread on the Ops ML confirmed. But then I'm (and
> maybe they are) still open to alternative suggestions...

This is probably a good entry point for my ACTION item from the
cross-project meeting:

I disagree that "time to time" tagging makes sense in what we are
trying to achieve.  I believe we are in agreement that we want to move
way from co-ordinated releases and treat each commit as an accessible
release.  Therefore, tagging each project at arbitrary times
introduces snowflake releases, rather than the importance being on
each commit being a release.

I agree that this would take away the 'co-ordinated' part of the
release, but still requires release management of each project (unless
the "time to time" is automated), which we are not sure that each
project will commit to.

If we are treating each commit to be a release, maybe we should just
bite the bullet and enlarge the ref tag length.  I've not done a
comparison of what this would look like, but I believe it to be rare
that people look at the list anyway.  Throwing in a | grep -v
"^$RELEASE*", and it becomes as usable as before.  We could also
expunge the tags after the release is no longer supported by upstream.

In my mind, we are then truly treating each commit as a release AND we
benefit from not needing hacky tooling to fake this.

--
Kind Regards,
Dave Walker