Hi,

> We definitely want to allow topic branches pushed to the main repo. *I
> think we'll have to agree on a namespace to use for these, perhaps
> following the dist-cvs example and call them private-*
>
> The way the ACL system works is that it matches on the refs you're
> pushing up, so for packages that have per-branch ACLs only the refs that
> match the branch have ACLs on them, and the assumption is that without
> an ACL you have no rights to it. *That's likely why your push failed,
> but I'd like to see the message to confirm.

$ git push origin private-topic-branch
Total 0 (delta 0), reused 0 (delta 0)
W refs/heads/private-topic-branch plymouth rstrode DENIED by fallthru
error: hooks/update exited with error code 255
error: hook declined to update refs/heads/private-topic-branch
To ssh://rstrode@pkgs.stg.fedoraproject.org/plymouth
! [remote rejected] private-topic-branch -> private-topic-branch
(hook declined)
error: failed to push some refs to
'ssh://rstrode@pkgs.stg.fedoraproject.org/plymouth'

--Ray

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Sorry, if I missed this in previous messages...

Are the cvs tags going to become git tags, or git branches? When I
checked out ~48 hours ago, it seemed like everything was a git branch,
which is not what I expected for the build tags.


kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags,
and not plain 'git tag'.


Jeff




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Dec 19, 2009, at 15:02, Jeff Garzik <jgarzik@pobox.com> wrote:



Sorry, if I missed this in previous messages...

Are the cvs tags going to become git tags, or git branches? When I
checked out ~48 hours ago, it seemed like everything was a git
branch, which is not what I expected for the build tags.


kernel.org admins recommend either 'git tag -a' or 'git tag -s'
tags, and not plain 'git tag'.





The cvs tags should become gi tags. If they aren't I'll have to look
into it.


--
Jes

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 12/19/09 11:04 AM, Tim Lauridsen wrote:
> On 12/19/2009 12:31 AM, Jesse Keating wrote:
>> Phase two, write access with ACLs, is ready for testing. Please not
>> that URLs have changed since my original announcement.
>>
>> git clone ssh://[fedoraaccount@]pkgs.fedoraproject.org/<package>
>>
>> will get you a cone via ssh, in which you can git pull and git push.
>>
>> The repos are the same from phase1, although I've done a few commits
>> here and there to test things. They are not tied to the CVS repos, so
>> changes you make here are truly throw away.
>>
>> Please test cloning and writing to packages and branches of packages
>> that you would normally have write access to, or normally would /not/
>> have write access to. I'm interested in seeing both of those cases
>> tried.
>>
>> Thanks again for your help in this project!
>>
>>
>
> Checked that I can checkout yumex and commit at change to yumex.spec to
> master and F-12 branch.
>
> Checked hat I can checkout kernel (F-10 and master) and i get a
>
> W access for kernel DENIED to timlau
> fatal: The remote end hung up unexpectedly
>
> If i try to commit some changes to the kernel.spec
>
> So it look like it work as expected.

Already talked with Jesse about it on irc, but for the benefit of the
list, I was able to pull, commit and push changes to the kernel just
fine, and was properly denied push on firefox.

And man, just 'git diff' performance vs. 'cvs diff' performance almost
on its own makes going forward with this change worth it, let alone all
the other reasons its so much better...

--
Jarod Wilson
jarod@redhat.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 12/19/2009 08:04 PM, Jesse Keating wrote:



On Dec 19, 2009, at 15:02, Jeff Garzik <jgarzik@pobox.com> wrote:



Sorry, if I missed this in previous messages...

Are the cvs tags going to become git tags, or git branches? When I
checked out ~48 hours ago, it seemed like everything was a git branch,
which is not what I expected for the build tags.

kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags,
and not plain 'git tag'.




The cvs tags should become gi tags. If they aren't I'll have to look
into it.


Yep, current pull looks fine that way. Everything is git tags, with
zero git branches.


Jeff


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating wrote:
> We definitely want to allow topic branches pushed to the main repo. I
> think we'll have to agree on a namespace to use for these, perhaps
> following the dist-cvs example and call them private-*

What about build branches? Let's say you have these committed to the F-12
branch:
foo-1.0-1.fc12
foo-1.0-2.fc12
foo-1.0-3.fc12
foo-1.1-1.fc12
foo-1.1-2.fc12

Now you see 1.1 is not ready to be queued as a Bodhi update yet (you may or
may not have it built for dist-f12-updates-candidate, it doesn't matter), so
you'd like to branch from foo-1.0-3.fc12 and create these:
foo-1.0-3.fc12.1
foo-1.0-3.fc12.2
…
or maybe these:
foo-1.0-4.fc12
foo-1.0-5.fc12
…
Either way, you want to branch from an old revision, create new ones in the
branch, and, what's different from a private topic branch, build the
packages from the branch for dist-f12-updates-candidate and eventually queue
them in Bodhi.

What's the best way to handle this?

Right now, in CVS, you can create a CVS branch within the F-12 branch as
long as you manage to create a branch name which passes validation and build
from there. (AFAIK, private-* branches can be abused for builds, and it's
also possible to create branches with names which look like build tags,
which also get through validation.)

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, 19 Dec 2009 10:56:57 -0800
Jesse Keating <jkeating@redhat.com> wrote:

> We definitely want to allow topic branches pushed to the main repo. I
> think we'll have to agree on a namespace to use for these, perhaps
> following the dist-cvs example and call them private-*

private/* would have the advantage of allowing easier branch name
wildcards in git ("git push origin 'private/*'").

OTOH, branch or tag names with slashes in them have the potential
to confuse tools and people.

> The way the ACL system works is that it matches on the refs you're
> pushing up, so for packages that have per-branch ACLs only the refs
> that match the branch have ACLs on them, and the assumption is that
> without an ACL you have no rights to it. That's likely why your push
> failed, but I'd like to see the message to confirm. It shouldn't be
> too hard to tweak the ACL creation script to add W access to anybody
> who has W access already to the private-* namespace.

Currently, it appears that I can push arbitrarily named branches, at
least if the package does not have per branch ACLs:

$ git push origin moo private/moo private-moo
Counting objects: 11, done.
Delta compression using 2 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 759 bytes, done.
Total 9 (delta 8), reused 0 (delta 0)
To ssh://ndim@pkgs.stg.fedoraproject.org/cstream
* [new branch] moo -> moo
* [new branch] private/moo -> private/moo
* [new branch] private-moo -> private-moo
$

And the same happens with (non-signed, non-annotated) tags:

$ git push origin meh private/meh private-meh
Total 0 (delta 0), reused 0 (delta 0)
To ssh://ndim@pkgs.stg.fedoraproject.org/cstream
* [new tag] meh -> meh
* [new tag] private/meh -> private/meh
* [new tag] private-meh -> private-meh
$

I guess even without per branch ACLs, the ACL system should take a look
at what I am actually pushing and verify its tag/branch names match some
kind of wildcard whitelist. For tags, it might also check their type
(annotated, signed).

--
Hans Ulrich Niedermann
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2009-12-20 at 09:46 +0100, Kevin Kofler wrote:
> Either way, you want to branch from an old revision, create new ones in the
> branch, and, what's different from a private topic branch, build the
> packages from the branch for dist-f12-updates-candidate and eventually queue
> them in Bodhi.
>
> What's the best way to handle this?
>
> Right now, in CVS, you can create a CVS branch within the F-12 branch as
> long as you manage to create a branch name which passes validation and build
> from there. (AFAIK, private-* branches can be abused for builds, and it's
> also possible to create branches with names which look like build tags,
> which also get through validation.)
>

I'm not a real fan of allowing official builds to happen from branches
like this. I'm ok with them being created and shared for various
topics, but the official builds should come from origin/master or
origin/F-?? Coming up with namespaces that we allow for shared repo
branches will be a discussion to have.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sun, 2009-12-20 at 10:28 +0100, Hans Ulrich Niedermann wrote:
> Currently, it appears that I can push arbitrarily named branches, at
> least if the package does not have per branch ACLs:
>

Yes, that makes sense given the way the ACL system works, it just wasn't
fully expected by me. A small change to the ACL generation script will
make sure that this sort of loophole is closed.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Jesse Keating wrote:
> I'm not a real fan of allowing official builds to happen from branches
> like this.

So what do you suggest doing in such a case? Temporarily reverting the F-n
branch to the old release, build, then bump it up again? This sounds really
suboptimal to me (in addition to being a regression from our current CVS
setup, which does allow creating such branches)! Branching is really part of
what VCSs are for.

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list