Re: Question regarding dist-git aesthetics with branches
ons 2010-07-21 klockan 11:48 -0700 skrev Jesse Keating: 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 I was just going to suggest this. f1x means built from git, fc1x means cvs. /Alexander -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Jesse Keating jkeat...@redhat.com writes: master - origin/master f13 - origin/f13/master f12 - origin/f12/master Please don't. The remote and local branches should be named the same so that git checkout -t origin/whatever does the right thing. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On 07/22/2010 10:19 AM, Andreas Schwab wrote: Jesse Keatingjkeat...@redhat.com writes: master - origin/master f13 - origin/f13/master f12 - origin/f12/master Please don't. The remote and local branches should be named the same so that git checkout -t origin/whatever does the right thing. Andreas. +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 11:48 -0700, Jesse Keating wrote: 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: 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. I would see f13/master - origin/f13/master as much more consistent than f13- origin/f13/master so your consistency argument would mandate the local repo's branches to be structured like master - origin/master f13/master - origin/f13/master f12/master - origin/f12/master or even better simply as master - origin/master f13- origin/f13 f12- origin/f12 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 This makes sense for the many occasions where the package maintainer local repo has exactly three branches on his system: f12, f13, and master. However, why have f13/master and f12/master on origin in the first place then? Shouldn't origin/master, origin/f13, and origin/f12 cover all branches koji ever needs to directly build from? Also, how would the proposed case of *local* f13/foo and f13/bar branches be handled here? Were we talking about having f13/foo in the official repos and building from branches like that? My reading now is that as my local repo already has a f13 branch upon initial clone and I need more that one local branch to build for F13, then I must manually rename f13 to some name like f13/official and only then can I fork off other f13/* branches. That would also require me to especially set up f13/official to be the new branch name to push to origin/f13... looks unnecessarily complicated. 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. It also seems a recipe for allowing the easy per-branch determination of the build target from the branch name just as you suggested earlier - but it would work both for the directly cloned branches and also for a bunch of local branches. And it would fulfil your requirement to work directly after a git clone of my local repo, without any additional setup. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Thu, 2010-07-22 at 10:19 +0200, Andreas Schwab wrote: Jesse Keating jkeat...@redhat.com writes: master - origin/master f13 - origin/f13/master f12 - origin/f12/master Please don't. The remote and local branches should be named the same so that git checkout -t origin/whatever does the right thing. Actually a good point, Andreas. +1 for remote and local branch names being the same. This will also help with the consistency simplifying build scripts that Jesse mentioned. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Jan Vcelak jvce...@redhat.com writes: On Thursday 22 July 2010 10:19:20, Andreas Schwab wrote: Jesse Keating jkeat...@redhat.com writes: master - origin/master f13 - origin/f13/master f12 - origin/f12/master Please don't. The remote and local branches should be named the same so that git checkout -t origin/whatever does the right thing. Not such an issue: git checkout -t origin/f13/master -b f13 Of course, you can name a branch any way you like, but that is not my point. I don't want to be forced to think about the branch name, because that is totally against common practice. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E And now for something completely different. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Dne 21.7.2010 08:22, Roland McGrath napsal(a): What does manually mean, anyway? A database query and a short script? Isn't this something which automatic QA process could do very easily? Matěj -- He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
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... :-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:55 +0200, 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:
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.
Ugly potential fix for this ugly issue: Patch rpm and yum to compare
N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 23:22 -0700, Roland McGrath wrote:
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.
Would this count as a core dump? :P
(Sorry)
Dave
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. Also IMO using only a single letter for the dist seems overly space optimizing ... if you just want to remove all references to Fedora Core, propose it changes to fed14 or even just rename what the c stands for (like the GCC rename). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:08 -0400, James Antill wrote: On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. Also IMO using only a single letter for the dist seems overly space optimizing ... if you just want to remove all references to Fedora Core, propose it changes to fed14 or even just rename what the c stands for (like the GCC rename). +1 on not just hard but REALLY ugly. Pretty confident that the rpm devs would reject such a patch, too. I know the yum devs will :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 10:08 -0400, James Antill wrote: On Wed, 2010-07-21 at 11:19 +0200, Hans Ulrich Niedermann wrote: Ugly potential fix for this ugly issue: Patch rpm and yum to compare N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15. That would be ... hard. And ugly doesn't even begin to describe it. I wholeheartedly agree. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wednesday, July 21, 2010 11:19:54 Hans Ulrich Niedermann wrote:
On Wed, 2010-07-21 at 10:55 +0200, 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:
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.
Ugly potential fix for this ugly issue: Patch rpm and yum to compare
N-V-R.fc13 exactly like N-V-R.f13, and carry that patch until F-15.
another less ugly (but still ugly) solution would be adding:
Obsoletes: N-V-R.fc13
Obsoletes: N-V-R.fc12
in koji automatically for the same NVR as the package has, but I don't know if
this would not make yum's depsolver cry
Michal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Wed, 2010-07-21 at 16:39 +0200, Michal Hlavinka wrote: another less ugly (but still ugly) solution would be adding: Obsoletes: N-V-R.fc13 Obsoletes: N-V-R.fc12 in koji automatically for the same NVR as the package has, but I don't know if this would not make yum's depsolver cry Even assuming we could make sure that does the correct thing (it probably would but I know it's not tested :), adding 40,000 obsoletes to the repo. is ... let's say: unlikely to make yum faster. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/whatsnew/3.2.28 http://yum.baseurl.org/wiki/YumBenchmarks http://yum.baseurl.org/wiki/YumHistory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-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-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/20/2010 11:22 PM, Roland McGrath wrote:
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.
Well, we don't have autoqa live as of yet, live enough to prevent n-v-r
mishaps from going out to users. So it would take some maintainer
diligence. Honestly though if we were going to make a dist eval change
I'd want to make it across all the active branches and reduce the
potential for n-v-r mishaps.
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.)
It'll live within fedpkg. It will basically make the assumption that if
you're on a branch, eg f13, it'll target
'dist-branch-updates-candidate'. And if you're not on a branch, it'll
target 'dist-rawhide'. We'll do koji magic to make sure 'dist-rawhide'
points things in the right direction, but the upshot is that nothing
needs to change on the developer's system each time we branch and start
up a new release.
Thanks,
Roland
- --
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/
iEYEARECAAYFAkxHQf0ACgkQ4v2HLvE71NX1SQCeOjfx6i8t+eYflJ5NknDZySvQ
zAcAoK9SgJKtQ7n1jSYXEInv4qdWgolp
=xVdV
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, Jul 20, 2010 at 00:33, Roland McGrath rol...@redhat.com wrote: My opinion is that a branch called F-n/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called fn/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) same here. I also prefer lower case. (package names and dist tags are lower-case too). I would avoid the magic with HEAD, it might be to confusing. master might also be confusing, but I can't think of anything better at the moment. f13/update or f13/release came to mind, but they are not very good either. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Fri, 2010-07-16 at 17:07 -0700, Jesse Keating wrote: I've been struggling with a particular wrinkle in dist-git, how fedpkg is supposed to reliably discover what Fedora release a packager is working on. In other words: How does fedpkg map the currently checked out git HEAD to a Fedora release? (Unless fedpkg is specifically given a Fedora release to build for on the command line.) In the CVS world, we used a branch file. This is OK, but I think it would be cleaner if we didn't have to rely upon that. It's the last file that wouldn't be exact across all the Fedora releases if a package is kept in sync. So what I'd like to do is rely upon discovering the top level upstream branch, say F-13. 100% Ack. This gets difficult if we allow maintainers to create and operate on their own upstream branches (which we should), as I have not found a reliable way to work from a local branch to which remote branch it tracks to which top level remote branch it was created from. Is this problem solvable at all? Every merge commit has (at least) two parents. If you have once merged the F-12 branch into the F-13 branch, how can fedpkg decide which of the parents was the real one to track back to? One suggestion has been to make use of directory based branching, so that any maintainer created branch is in a subdir of a top level branch. This phrasing might be a little confusing. We are NOT talking about having different branches' files in different subdirectories on the filesystem here, like we were doing with the CVS checkouts. We are talking about branches named like directories (e.g. 'F-13/foo'). EG we'd a user could create an F-13/kernel-2.7 branch, and call it whatever they want locally. fedpkg would be able to work from the local branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the path from origin/ to discover F-13. Then fedpkg can assume F-13 for the branch and do all the dist conversions and koji target discovery from that. This doesn't put too much restraint on what maintainers call their branches, particularly locally. The wrinkle with the above though is the base top level branch. When we do this with directories, it's not possible to have a simple origin/F-13 branch that a user could interact with (git checkout F-13 would automatically detect that there is an origin/F-13 remote branch and setup a local F-13 branch to track it and still allow for an F-13/foobar branch. So we have to make the first base upstream branch F-13/something. One suggested something has been to call it HEAD, because git seems to have another short cut that would allow you to do git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it will automatically use that. HEAD seems to be a special name in this context. However it is pointed out that using HEAD here could be confusing to people who are more familiar with git and naming conventions. Another suggestion is to call it F-13/master since master is a more appropriate and expected name. However that means you can't use the short cut and have to do a full git checkout -b F-13 origin/F-13/master. Since you have to use the full path here, we aren't bound by the name master and we could name it anything we want, something that might make sense to Fedora or dist-git. I would call it something short and sweet and to the point. Using F-13/HEAD appears hackish, and does things one might not expect, so I would be careful with that. Whether it is called F-13/master, F-13/koji, or F-13/official, however, I don't care, as long as it is consistent over all packages. Now, these are fairly low details which can be hidden behind fedpkg (there is a proposed patch to give fedpkg a 'switch-branch' command that will switch you from one to the other, and we can make calls to F-13 attempt origin/F-13/master or whatever), but I feel that this is a detail I shouldn't just decide on my own. So, I welcome the discussion. My first idea would be for fedpkg to do something similar to the following when trying to find out the target to build for: 0. If --target F-13 is given, use that as target. If not, continue. 1. Determine the current git branch ($origbranch=$curbranch). 2. Check 'git config branch.$curbranch.fedora-target'. If set, use that as target. If not, continue. 3. Check whether $curbranch starts with F-13/. If so, use F-13 as the target. If not, continue. 4. Check what branch $curbranch is tracking. If it tracks one, set curbranch to that branch and go to step 2. Otherwise, bail out and ask for --target or 'git config branch.$origbranch.fedora-target' to be set. This would allow * Easy building of the currently checked out branch for all targets with something like fedpkg mockbuild --target F-13. * Easy building of some special local branch for F-13 by default even if it is not called F-13/foo. * Building of branches for the
Re: Question regarding dist-git aesthetics with branches
On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. That said, I don't think I'd use either HEAD or master as the branch name since they both have some sort of association with how git itself works unless the name actually matches 100% with the concept that you're trying to express here. When you make a UI choice where a feature has the same name as another feature but they are onlt 80% compatible you cause problems for the people that try to do something in that 20% space. When they switch from one feature to the other they run into incompatibilities, googling will turn up the wrong feature, they will ask on IRC and get answers that concern the wrong feature, etc. It's better to have a distinct name for something that is different. -Toshio pgp9RXWzt1rBW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 05:52 AM, Hans Ulrich Niedermann wrote: On Fri, 2010-07-16 at 17:07 -0700, Jesse Keating wrote: I've been struggling with a particular wrinkle in dist-git, how fedpkg is supposed to reliably discover what Fedora release a packager is working on. In other words: How does fedpkg map the currently checked out git HEAD to a Fedora release? (Unless fedpkg is specifically given a Fedora release to build for on the command line.) That's right. In the CVS world, we used a branch file. This is OK, but I think it would be cleaner if we didn't have to rely upon that. It's the last file that wouldn't be exact across all the Fedora releases if a package is kept in sync. So what I'd like to do is rely upon discovering the top level upstream branch, say F-13. 100% Ack. This gets difficult if we allow maintainers to create and operate on their own upstream branches (which we should), as I have not found a reliable way to work from a local branch to which remote branch it tracks to which top level remote branch it was created from. Is this problem solvable at all? Every merge commit has (at least) two parents. If you have once merged the F-12 branch into the F-13 branch, how can fedpkg decide which of the parents was the real one to track back to? I don't think it is solvable, without enforcing some form of naming convention. One suggestion has been to make use of directory based branching, so that any maintainer created branch is in a subdir of a top level branch. This phrasing might be a little confusing. We are NOT talking about having different branches' files in different subdirectories on the filesystem here, like we were doing with the CVS checkouts. We are talking about branches named like directories (e.g. 'F-13/foo'). I'm going to make it slightly more confusing here, but bear with me. As far as the client is concerned and maintainer checkouts, there will not be a subdirectory. These are real git branches and you switch between them which will update your working copy. The branches would just be named with a directory like structure. Now, on the back end, the git repo server, the git metadata would actually create a F-13 directory and put things like the master and other files within that directory. Clients don't care about this, but it does make some things convenient when looking at the git repo structure. There is also a fedpkg command that will setup your git checkouts to look like it did with CVS, where you have module/devel module/F-13 module/F-12 etc... and there would be a clone/checkout in each of those subdirs from the appropriate remote branch. EG we'd a user could create an F-13/kernel-2.7 branch, and call it whatever they want locally. fedpkg would be able to work from the local branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the path from origin/ to discover F-13. Then fedpkg can assume F-13 for the branch and do all the dist conversions and koji target discovery from that. This doesn't put too much restraint on what maintainers call their branches, particularly locally. The wrinkle with the above though is the base top level branch. When we do this with directories, it's not possible to have a simple origin/F-13 branch that a user could interact with (git checkout F-13 would automatically detect that there is an origin/F-13 remote branch and setup a local F-13 branch to track it and still allow for an F-13/foobar branch. So we have to make the first base upstream branch F-13/something. One suggested something has been to call it HEAD, because git seems to have another short cut that would allow you to do git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it will automatically use that. HEAD seems to be a special name in this context. However it is pointed out that using HEAD here could be confusing to people who are more familiar with git and naming conventions. Another suggestion is to call it F-13/master since master is a more appropriate and expected name. However that means you can't use the short cut and have to do a full git checkout -b F-13 origin/F-13/master. Since you have to use the full path here, we aren't bound by the name master and we could name it anything we want, something that might make sense to Fedora or dist-git. I would call it something short and sweet and to the point. Using F-13/HEAD appears hackish, and does things one might not expect, so I would be careful with that. Whether it is called F-13/master, F-13/koji, or F-13/official, however, I don't care, as long as it is consistent over all packages. Now, these are fairly low details which can be hidden behind fedpkg (there is a proposed patch to give fedpkg a 'switch-branch' command that will switch you from one to the other, and we can make calls to F-13 attempt origin/F-13/master or whatever), but I
Re: Question regarding dist-git aesthetics with branches
That said, I don't think I'd use either HEAD or master as the branch name since they both have some sort of association with how git itself works unless the name actually matches 100% with the concept that you're trying to express here. This is nothing more or less than our convention for git branch names, so the generic git conventions for branch names exactly match the concept. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
My first idea would be for fedpkg to do something similar to the following when trying to find out the target to build for: 0. If --target F-13 is given, use that as target. If not, continue. 1. Determine the current git branch ($origbranch=$curbranch). 2. Check 'git config branch.$curbranch.fedora-target'. If set, use that as target. If not, continue. 3. Check whether $curbranch starts with F-13/. If so, use F-13 as the target. If not, continue. 4. Check what branch $curbranch is tracking. If it tracks one, set curbranch to that branch and go to step 2. Otherwise, bail out and ask for --target or 'git config branch.$origbranch.fedora-target' to be set. I'd suggested something just about like this. Jesse is concerned by the fact that some local state (the .git/config file in your local repo) affects this. I think the fear is that you could easily manage to confuse yourself about what magic cookie is driving your dwim build target behavior, so another developer you're collaborating with might end up having a local git repo you both looks the same as yours, but builds pick a different target. My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. I can see both sides of Jesse's point about the extra locally-confusable magic setting here. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 09:03 -0400, Toshio Kuratomi wrote: On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. Definitely this is where I stand. It's too new and different for me to have a reliable mental map of it to know what to think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 03:07 PM, Adam Williamson wrote: On Tue, 2010-07-20 at 09:03 -0400, Toshio Kuratomi wrote: On Mon, Jul 19, 2010 at 03:09:50PM -0700, Jesse Keating wrote: Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... I'm not around enough right now to be able to test anything :-(. I also don't really understand the choices you're presenting since they're based on git conventions that I don't know. master is just a convention in git? HEAD is treated specially but doesn't exist normally in a repository? I think the only way to do this is to implement one thing and then be willing to either change that (or let someone else contribute work to change it) once people use it and tell you ZOMG WHY [...]. Definitely this is where I stand. It's too new and different for me to have a reliable mental map of it to know what to think. Thankfully it's pretty easy to move this stuff around if we need to after the conversion. It may break people's existing clones, but those are cheap. - -- 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/ iEYEARECAAYFAkxGH/MACgkQ4v2HLvE71NUxbgCeN3f4zmg4oyiig+f35LqzriUq YwcAnRbz4aLYDgOGtDtTyDW8IEpegQqH =5QUJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
Roland McGrath wrote: My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. +1 to this. After switching from CVS to git for my own projects over the course of the past year I am beginning to see the high value in branching with git. Linus' suggestion of using branches everywhere is something hard to grasp at first but it is the right direction. Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Keeping separate directories per release seems cumbersome and I just submitted my first package yesterday. You guys have been doing far too much work with the current method of package upkeep. :P -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/20/2010 03:32 PM, Michael Cronenworth wrote: Roland McGrath wrote: My first suggestion was not to have the magical leading F-n/ matching at all. Rather, just have fedpkg front-end commands set and show the state of branch.SOMEBRANCH.fedora-target settings. e.g., 'fedpkg checkout foo' would both do 'git checkout foo' and set the branch.foo.fedora-target automatically. +1 to this. After switching from CVS to git for my own projects over the course of the past year I am beginning to see the high value in branching with git. Linus' suggestion of using branches everywhere is something hard to grasp at first but it is the right direction. Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Keeping separate directories per release seems cumbersome and I just submitted my first package yesterday. You guys have been doing far too much work with the current method of package upkeep. :P I think you've misunderstood the proposal. There won't be separate directories per release, just separate branches. The branch names will look like they have directory structure though, which will help programatically detect the Fedora target. - -- 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/ iEYEARECAAYFAkxGKrUACgkQ4v2HLvE71NXRAQCfaNvQ78C3OKvp8uSd/uX+Uu1r wT4An2KH7XmN/QVTBxG1GTGhcbgkbjZM =FpZ/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, 2010-07-20 at 17:32 -0500, Michael Cronenworth wrote: Here's one nice feature I'd like to see for a simple scenario of when upstream releases a new stable version: 1. Edit the 'master' branch spec file. 2. git commit my change. 3. git rebase my F-* branches to master. 4. Submit my builds! Uhm. Rebase, i.e. rewriting branch history, and requiring a git push -f to force non-fast-forward merging of the public branches? Is that really a good idea? I would have presumed something like (using pseudo names for the branches) F-13 --o-m / master O \ F-12 -o--m if you are keeping F-12 and F-13 in sync or devel ---O \ F-13 -m \ F-12 ---m if you are keeping all three branches devel, F-13, F-12 in sync. A subsequent push (without -f) of the F-13 and F-12 (and devel in the second case) branches and a build request would conclude the process. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
On Tue, Jul 20, 2010 at 9:54 AM, Christof Damian chris...@damian.net wrote: On Tue, Jul 20, 2010 at 00:33, Roland McGrath rol...@redhat.com wrote: My opinion is that a branch called F-n/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called fn/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) same here. I also prefer lower case. (package names and dist tags are lower-case too). +1 for lower-case branch names without punctuation. -- Iain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
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}.
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?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
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.
- --
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/
iEYEARECAAYFAkxGgokACgkQ4v2HLvE71NV8WwCfcVOK9lNRJwb+RQJC22Ngixk3
Oa0AoMVsIdKMM3xqw28UwibrivN5Fy9z
=hKZP
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/16/10 5:07 PM, Jesse Keating wrote: I've been struggling with a particular wrinkle in dist-git, how fedpkg is supposed to reliably discover what Fedora release a packager is working on. In the CVS world, we used a branch file. This is OK, but I think it would be cleaner if we didn't have to rely upon that. It's the last file that wouldn't be exact across all the Fedora releases if a package is kept in sync. So what I'd like to do is rely upon discovering the top level upstream branch, say F-13. This gets difficult if we allow maintainers to create and operate on their own upstream branches (which we should), as I have not found a reliable way to work from a local branch to which remote branch it tracks to which top level remote branch it was created from. One suggestion has been to make use of directory based branching, so that any maintainer created branch is in a subdir of a top level branch. EG we'd a user could create an F-13/kernel-2.7 branch, and call it whatever they want locally. fedpkg would be able to work from the local branch name to what it tracks (origin/F-13/kernel-2.7) and walk down the path from origin/ to discover F-13. Then fedpkg can assume F-13 for the branch and do all the dist conversions and koji target discovery from that. This doesn't put too much restraint on what maintainers call their branches, particularly locally. The wrinkle with the above though is the base top level branch. When we do this with directories, it's not possible to have a simple origin/F-13 branch that a user could interact with (git checkout F-13 would automatically detect that there is an origin/F-13 remote branch and setup a local F-13 branch to track it and still allow for an F-13/foobar branch. So we have to make the first base upstream branch F-13/something. One suggested something has been to call it HEAD, because git seems to have another short cut that would allow you to do git checkout -b origin/F-13 and since it finds an origin/F-13/HEAD it will automatically use that. HEAD seems to be a special name in this context. However it is pointed out that using HEAD here could be confusing to people who are more familiar with git and naming conventions. Another suggestion is to call it F-13/master since master is a more appropriate and expected name. However that means you can't use the short cut and have to do a full git checkout -b F-13 origin/F-13/master. Since you have to use the full path here, we aren't bound by the name master and we could name it anything we want, something that might make sense to Fedora or dist-git. Now, these are fairly low details which can be hidden behind fedpkg (there is a proposed patch to give fedpkg a 'switch-branch' command that will switch you from one to the other, and we can make calls to F-13 attempt origin/F-13/master or whatever), but I feel that this is a detail I shouldn't just decide on my own. So, I welcome the discussion. I also welcome anybody challenging the above assumptions and showing us an even better way of managing the branch naming and discovering client side what Fedora target a maintainer wishes to work against. I will however put some constraints on that. A maintainer shouldn't have to modify anything in their local clone to indicate what target, fedpkg should be able to do a clone of a repo, switch to a branch (which may be a branch of a branch of a branch) and be able to discover what the target should be. Thanks! Seriously? Nobody has an opinion here? Or will this just be another case of ZOMG WHY DID YOU DO THIS STUPID THING as soon as it rolls out... - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxEzSsACgkQ4v2HLvE71NUemwCcDatkXaTQV1+2Kji7AwtATWkO dmYAoJaZMAkUY5lLWhIsDqa7moXyymKp =K2b5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Question regarding dist-git aesthetics with branches
My opinion is that a branch called F-n/master is the nicest thing. Actually, all else being equal, I'd probably go for it being called fn/master, since gratuitous caps and punctuation in branch names is not a normal git convention. (But I only really care about the structure of the names, not the spelling.) I don't really care whether you have an F-n/HEAD alias to that or not. I don't really care whether fedpkg provides front-end features to git that relieve one of knowing the actual branch name or not. Personally, I'd always look at the canonical git repository to see what the branches are called, and use those full names directly. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
