-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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!
- --
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/
iEYEARECAAYFAkxA9DgACgkQ4v2HLvE71NU9hwCghhorcU8oz/gAWKk3h76q+h7r
T2sAn0MfdRwHR+niHYQPIAWkaMhHLF1f
=xc1g
-----END PGP SIGNATURE-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
