Open Stack

Dave Walker wrote:
> 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.

Thanks for this. I agree that time-to-time is far from being a perfect
solution. The question is more, is it better or worse than the other
solution (tag-every-commit). To summarize:

Tag-every-commit:
(+) Conveys clearly that every commit is consumable
(-) Current tooling doesn't support this, we need to write something
(-) Zillions of tags will make tags ref space a bit unusable by humans

Time to time tagging:
(+) Aligned with how we do releases everywhere else
(-) Makes some commits "special"
(-) Making a release still requires someone to care

Missing anything ?

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

What hacky tooling you are thinking about here ? If anything,
time-to-time tagging reuses the release process we have for everything
else, so it doesn't require any additional tooling. It's "tag every
commit" that requires some hack to happen.

-- 
Thierry Carrez (ttx)