Open Stack

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)