-----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 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.
I debated that. Given that this configuration is not shared with the
remote repo, and thus other contributors who might have cloned I'm not
sure I want to support that, and would prefer to rely upon manual
override with --target.
> 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.
That all seems relatively sane, and it something that can be adjusted as
we go in fedpkg without having to change anything on the repo side.
>
> 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.
>
>
Of course. I should have mentioned that, but I had always planned for that.
- --
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/
iEYEARECAAYFAkxF2YUACgkQ4v2HLvE71NUlVQCfccbEsBM/VzlAl+egHKW7UBbw
vFcAniJEwH607wc2oZ+3USbnwmNJ9CVN
=Rp2U
-----END PGP SIGNATURE-----
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
