dist-git proof of concept phase 2 ready for testing

Jarod Wilson jarod at redhat.com
Wed Dec 23 20:46:26 UTC 2009

On 12/23/09 3:21 PM, Jesse Keating wrote:
> On Wed, 2009-12-23 at 19:28 +0100, Kevin Kofler wrote:
>> The whole problem is that such branches do not exist at all in the new git 
>> setup!
>>> If you get eaten by raptors, you can't expect another maintainer to come
>>> in after you and have to dig around for a private branch to update a
>>> build.
>> That's why we need non-private branches (more than one per release), as 
>> allowed by our current CVS setup.
> Perhaps we have a terminology clash.
> The dist-git proof of concept allows branches to be created by
> maintainers, and pushed to the central repo, so long as the branch name
> starts with "private-".  These repos can be written to by anybody with
> file system write access, that is anybody in the 'packager' group.
> At this time, I am not planning to allow official tagged builds to come
> from these branches, instead they can only come from origin/master or
> origin/F-??

Okay, we've definitely got some slight misunderstanding here... :)

I was objecting to Kevin's suggestion that we should be able to build
official packages from branches named ^private-*. But building from a
branch tagged something !^private- is actually necessary sometimes.

The kernel folks have had to do just that from time to time. For
example, say the F12 cvs head moves on towards 2.6.32 and an official
build is submitted to updates-testing. Meanwhile, a security update for
the already-released-to-users 2.6.31.x kernel needs to get pushed out.
We create an F12-specific 2.6.31.x branch and build an *official* kernel
to push to updates post-haste to fix the security issue. This *does*
need to be allowed. But it wouldn't be on a branch named "private-*", it
would be quite blatant and obvious in naming, such as
f12-2_6_31_x-kernel-branch or similar.

I think there was some confusion in my use of "private branch", where I
was referring to branches with a name ^private-*, while Kevin was
thinking in a more general sense, which would encompass the above kernel

Jarod Wilson
jarod at redhat.com

More information about the fedora-devel-list mailing list