Question regarding dist-git aesthetics with branches

[Hans Ulrich Niedermann]

On Tue, 2010-07-20 at 22:15 -0700, Jesse Keating wrote:

> On 07/20/2010 08:55 PM, Garrett Holmstrom wrote:
> > On 7/20/2010 19:13, Hans Ulrich Niedermann wrote:
> >> BTW, while typing the above, I have noted that "master" or "devel" or
> >> "f13" are quite easy to type, while "F-13" with capital letter and
> >> hyphen is relatively complicated. Perhaps that could be an argument when
> >> choosing branch names.
> > 
> > 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}.
> 
> 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.

Don't we have a (few) mass rebuilds in front of us before F-14 anyway?
gold and similar stuff? That would increase the R of N-V-R anyway, so we
could switch %{dist} from fc14 to f14 at the same time for probably the
majority of packages.

Oh. Darn. We still need to make sure that *.fc12 and *.fc13 packages do
not have the same N-V-R modulo %{dist} as F14 has, until F13 is EOLed,
i.e. until F15 comes out. That still sounds ugly. Well, all of that is
ugly regarding the "c", whatever we do or do not do.

> > If rawhide development is supposed to happen on origin/master, then how 
> > do branches for rawhide work?  Does fedpkg just default to building for 
> > rawhide when a branch doesn't appear in a release's "branch namespace?"
> 
> 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.

I was not aware that rawhide would be basically origin/master. In that
case, it would be really obviously nice to be able to have branches
"master", "f13" and "f12" (without any slashes) in the local repo and
have things "just work" for that case.

Perhaps fedpkg could support both "simple" clones where the developer's
local repo has just three branches tracking upstream

     master -> origin/master
     f13    -> origin/f13/master
     f12    -> origin/f12/master

or for people with more complex needs

     master     -> origin/master
     f13/master -> origin/f13/master
     f12/master -> origin/f12/master

Which gives me an idea. What if we had

     master     -> origin/master
     f13        -> origin/f13
     f12        -> origin/f12
     F13/foo
     F12/bar

and in addition to that, any local branch named like "F13/*" would be
built for f13? That would give direct 1:1 git repo cloning, with still
making it possible to deduce the target from branch names if so desired
by the packager.

We could even use "fc13" and "f13/foo" to make the confusion complete
and nail down the "c" requirement for the next 20 years... :-)