Question regarding dist-git aesthetics with branches

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/21/2010 01:55 AM, Hans Ulrich Niedermann wrote:
> 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.

The majority of packages aren't going to be rebuilt.

> 
> 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.

The other option is to make the dist translation change on the other
branches too, so that future f12 and f13 builds have a dist of ".f12"
and ".f13"

> 
>>> 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

The problem is in inconsistency.  Makes things harder for scripted
rebuilds which I'd expect to run on the f13/master branch.  For the
local clone, I was going to have fedpkg call the branches by their base
name, so

master -> origin/master
f13 -> origin/f13/master
f12 -> 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.

hrm, I'm not really in favor of having both "f13" and "F13/foo", that
just seems like a recipe for lots of typo disasters.

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


- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkxHQOMACgkQ4v2HLvE71NWGqwCgoae3JCgIgCosQwQC+fVDGiTs
wK0AoL+bIW8hEdJP/jlsJefhyAgSVBiw
=NDAr
-----END PGP SIGNATURE-----