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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
