Open Stack

> -----Original Message-----
> From: Dave Walker [mailto:email at daviey.com]
> Sent: 21 August 2015 12:43
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable
> release notes
> 
> 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
> 

I do not like about the time to time tagging either, but I don't think it's totally horrible situation. Lets say we tag every even week Wednesday and in event of OSSA.

The big problem with every commit being release in stable is that lots of tooling around git really doesn't care if the reference is branch or tag in branch X. Say I can't remember how I named my branch I'm working on and I do `git checkout <tab><tab>` there is difference if that list suddenly is on hundreds rather than dozens. So yes some level of deprecation period to clean those old tags would be great at the point we stop support for certain branches.

I do realize that I'm not the git guru, so if there is really simple way to configure that, please let me know and ignore the above. ;)

- Erno
> __________________________________________________________
> ________________
> 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