Dave Walker wrote: > On 21 August 2015 at 11:38, Thierry Carrez <thie...@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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
