Question regarding dist-git aesthetics with branches

[Roland McGrath]

> > Using names like f13, el5, and so forth would also keep dist-git 
> > consistent with git branch naming conventions.  If we were to do 
> > something like that we might as well just use the value of %{dist}.

But that's just too obviously right for us to be allowed to do it!

> That was going to be my next question, although that would bring back
> the "c" in fc13 and fc14 since that's what the dist value is.  We could
> bite the bullet and change the dist value to remove the c, and just
> manually keep track of making sure that builds on older releases won't
> be "newer" than builds on the newer branches.  not sure if we want to go
> through that pain at this point.

I'd say bite the bullet.  Die, little c, die!  It just looks silly there
nowadays, since the C-word has not been in our vocabulary for so long now.

What does "manually" mean, anyway?  A database query and a short script?
Roll it into existing nag mail or update sanity-checking stuff?  This seems
like a simple enough matter among all the things we're nowadays trying to
have some coherent checking for.

> Yes. Branches of rawhide would be of the form origin/<branch> so if we
> don't find one of our expected f(c)??,el?,olpc? we default to building
> for rawhide.

Where is the mapping of branch name patterns to koji build targets going to
live?  Is it just in fedpkg locally and you'll change the norm only by
pushing a fedora-packager update in each release?  (That doesn't sound very
likely.  People use older Fedoras with older fedora-packager installed to
commit and trigger newer dist builds.)  Or is it partly local and partly
gotten from the (koji?) server, or what?  (In the CVS system this is the
common/branches file, which is both locally available in that it's a local
file in your common/ checkout, and centrally maintained in CVS.)


Thanks,
Roland