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 proper default target if the user
has made no special local efforts like "git config" or "--target".
The issue of how exactly to call the branches koji builds from, and how
exactly the F-13/master or F-13/HEAD or F-13/koji should be called is
independent.
> 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.
Ack, but support for local overrides still makes sense to me.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
