Jay Pipes wrote: > [...] > = Packaging tags should be release-specific, or they will be wrong = > > For these packaging tags, the release must be part of the tag itself, > otherwise the information it denotes would be indeterminate. > > As an example, suppose you have a tag that looks like this: > > ops:packaged:centos:good > > And in the tag definition you say that the tag is applied to projects > that have CentOS RPM packages available "within the last 6 months". > Well, as you all know, packages are published for a *particular release > of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in, > say, August 2015, the tag would ostensibly be saying that packages exist > for Nova in Kilo. However, once November rolls around, and packages for > Liberty don't (yet) exist, are you going to remove this > "ops:packaged:centos:good" tag from Nova or (worse) change it to > "ops:pacakged:centos:no"? > > Instead, have the tag be specific to a release of OpenStack: > > packaged:centos:kilo
There is a provision in the tag framework for (secondary) attributes. So far we only used it to track the "since when" information on the "integrated-release" legacy tag. If packaging basically carries over, the only interesting bit of information is "what is the first release cycle the packaging appeared in", so you could actually have: - repo: openstack/nova tags: - name: packaged:centos since: diablo I think it's easier and simpler to maintain. -- 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