This gets created when we branch, and won't likely change even up to the final release tree. What would you suggest we use there instead of "rawhide"?

We should probably have written this down ages ago, this is off the top of my head ... but at least will stay around longer than IRC :).

The idea is that eventually we want to be able to work out a few things on the client side with the tags:

• is it binary or source?
• If binary which arches does it have?
• what level of "stability" is it at, so we can warn/notify users: rawhide, testing, stable.
• Is this a release or updates?
• some kind of grouping, so we can tell:
• If we want to "enable source" or "enable debuginfo" we can do it within the groups, instead of doing hacks based on repoid.
• If we happen to have "rpmfusion-free" for F-12, and we are on F-13.
• Do things like "disable update repos" and "enable updates testing" (this would include rpmfusion-updates-testing too) and maybe "disable all of rpmfusion".

...my understanding was that we could probably do that with just two tags and so we were going to have:

• F-n release binary x86_64:
• content tags: binary-x86_64 binary-i686

• dist tag: cpe:fedora:13=release

• F-n updates binary x86_64:

• content tags: binary-x86_64 binary-i686

• dist tag: cpe:fedora:13:updates=release

• F-n updates-testing binary x86_64:

• content tags: binary-x86_64 binary-i686

• dist tag: cpe:fedora:13:updates=testing

• F-n updates source:

• content tags: source

• dist tag: cpe:fedora:13:updates=release

• F-n+1 rawhide binary x86_64:

• content tags: binary-x86_64 binary-i686
• dist tag: cpe:fedora:14=rawhide

...the idea being that we could then ask rpmfusion to use something like dist tag: cpe:fedora:13:rpmfusion:free=release etc.

the content tag being just a single binary-$basearch isn't the end of the world, although all the arches in the repo. would be "nicer". The distro. tag is pretty useless atm. though :(.

Sounds to me like we need to have a conversation with the other producers and consumers of these tags. I think we've proven we can generate some of the tags, we just need some agreement on what they are going to be. Can you do that and report back when you have a more firm idea of what you want listed?

James/Seth - more info on what you want?

Who are these other consumers? AFAIK this just needs to be something that koji starts doing to an ad hoc "std." ... then we can goto rpmfusion/etc. and say "do this, and get features X, Y and Z".

If you want to have a phone call, arrange one.

I note that F-14 fedora repomd currently has:

<distro cpeid="cpe:/o:fedoraproject:fedora:14">rawhide</distro>

...where something like "prerelease" or would be nicer, and then "release" when it's goes GA.

Right now, these values are driven by mash config files. While it's relatively easy to change the branched config file to say something like "prerelease", it gets trickier to change that to say "release" when that time comes. This is because to compose out the release repos, we just copy the branched compose over to the Everything/ tree (and scrub the installer bits along the way). So we would have to make the mash config change before we start making release candidates, and then we'd have a repo in development/ saying that it's "release". Either that or we have to re-run createrepo on the Everything tree to change out this value. Do-able, but human error prone.

Also, if you want the multilib dirs to list binary-<arch> and binary-<multiarch> that would require more changes in mash.

Probably the "safest" route here is to have a release ticket item to edit the mash file when we reach our final change deadline and start trying to make a release candidate so that the tags go from "prerelease" to "release". Thoughts?

It does not appear that there is something that needs to be done anymore. If there is, please re-open this ticket.