5:31 p.m.
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!
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:37 p.m.
On Fri, 18 Dec 2009 15:31:49 -0800
Jesse Keating <jkeating(a)redhat.com> 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>
git clone ssh://[fedoraaccount@]pkgs.stg.fedoraproject.org/<package>
as far as I can tell.
--
Hans Ulrich Niedermann
6:44 p.m.
On Dec 18, 2009, at 16:37, Hans Ulrich Niedermann <hun@n-
dimensional.de> wrote:
On Fri, 18 Dec 2009 15:31:49 -0800
Jesse Keating <jkeating(a)redhat.com> 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>
git clone ssh://[fedoraaccount@]pkgs.stg.fedoraproject.org/<package>
as far as I can tell.
Crap. I did it again. Thanks for catching that. That is what I get for
rushing a message out before taking off.
--
Jes
10:04 a.m.
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.
Tim
11:07 p.m.
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(a)redhat.com
10:42 a.m.
2009/12/18 Jesse Keating <jkeating(a)redhat.com>:
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.
I checked out emacs-vm and the commited and pushed a change to the
spec file and was quite surprised to find that the change was pushed
to all branches. Is that intended ?
10:55 a.m.
2009/12/19 Jonathan Underwood <jonathan.underwood(a)gmail.com>:
I checked out emacs-vm and the commited and pushed a change to the
spec file and was quite surprised to find that the change was pushed
to all branches. Is that intended ?
Er, ignore that, I was confusing myself.
11:28 a.m.
On Dec 19, 2009, at 8:42, Jonathan Underwood <jonathan.underwood(a)gmail.com
wrote:
2009/12/18 Jesse Keating <jkeating(a)redhat.com>:
> 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.
I checked out emacs-vm and the commited and pushed a change to the
spec file and was quite surprised to find that the change was pushed
to all branches. Is that intended ?
Um, no. I'll look at this module and see what happened.
--
Jes
11:41 a.m.
Hi,
On Fri, Dec 18, 2009 at 6:31 PM, Jesse Keating <jkeating(a)redhat.com> 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.
So one thing I tried is to create a custom topic branch (a la private-
branches in pkgs cvs), and pushing it failed.
Is this something we want to support? Or should topic branches be
pushed to separate private respositories?
--Ray
12:56 p.m.
On Sat, 2009-12-19 at 12:41 -0500, Ray Strode wrote:
So one thing I tried is to create a custom topic branch (a la
private-
branches in pkgs cvs), and pushing it failed.
Is this something we want to support? Or should topic branches be
pushed to separate private respositories?
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. 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.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:02 p.m.
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
5:02 p.m.
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
7:04 p.m.
On Dec 19, 2009, at 15:02, Jeff Garzik <jgarzik(a)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
11:25 p.m.
On 12/19/2009 08:04 PM, Jesse Keating wrote:
On Dec 19, 2009, at 15:02, Jeff Garzik <jgarzik(a)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
2:46 a.m.
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
9:30 p.m.
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
10:06 p.m.
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
10:40 p.m.
On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote:
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.
You're right, branching is a real part, that's why you would start the
foo-1.1 work on a topic branch, and only merge it into origin/F-12 when
you're ready to build it and push it through bodhi. Just like you'd
work on a new feature on a feature branch and only bring it over to
origin/master when you're ready to merge it with everything else.
Treat the origin/F-?? as the master for that release, do your long
running not immediately ready for build work on topic branches thereof
and only merge them when you're ready to build. This reduces the
surprise should another developer need to quickly build out an update
that is unrelated to any major change you may have cooking.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:50 a.m.
2009/12/21 Jesse Keating <jkeating(a)redhat.com>:
On Mon, 2009-12-21 at 05:06 +0100, Kevin Kofler wrote:
> 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.
You're right, branching is a real part, that's why you would start the
foo-1.1 work on a topic branch, and only merge it into origin/F-12 when
you're ready to build it and push it through bodhi. Just like you'd
work on a new feature on a feature branch and only bring it over to
origin/master when you're ready to merge it with everything else.
Treat the origin/F-?? as the master for that release, do your long
running not immediately ready for build work on topic branches thereof
and only merge them when you're ready to build. This reduces the
surprise should another developer need to quickly build out an update
that is unrelated to any major change you may have cooking.
Something that would be really nice on top of this would be allowing
*any* contributor to create and push private/topic branches while only
allowing contributors allowed by the ACL to push to the branches from
which builds occur.
Use case: I see a problem with a package. I fix it and push to a topic
branch, and then contact the package owners and ask them to merge it.
Faster workflow than going through bugzilla.
This might all be one pony too far at this stage though, and might be
phase 10 wishlist stuff.
J
12:56 p.m.
Jesse Keating wrote:
Treat the origin/F-?? as the master for that release, do your long
running not immediately ready for build work on topic branches thereof
and only merge them when you're ready to build.
This requires us to know in advance that the work will be long running. In
my experience, this is usually only noticed once the new version has been
imported (with the intent to build it right away), or even once it made it
to testing and got massive negative karma (after all, that's what testing is
for: as the name says, stuff there needs to get tested and can fail).
One case where I had to branch off an old build: I noticed on December 14
that the September 30 kde-plasma-networkmanagement snapshot had been pushed
only to F11 updates and not to F12, breaking the upgrade path. By then, the
F-12 branch had moved on to an October 24 snapshot, but I didn't want to
rush out a newer, untested snapshot to fix the upgrade path, but instead
queue the same one as on F11. (In addition, the October 24 snapshot is
outdated too, Rawhide has a newer one, but current snapshots require Qt
4.6.) But the corresponding F12 build had already been deleted by Koji, so I
had to branch and rebuild a new one. I used the "create a branch with a name
which looks like a build tag to the tag validator" hack and branched
kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that
branch.
Kevin Kofler
2:01 p.m.
On Mon, 2009-12-21 at 19:56 +0100, Kevin Kofler wrote:
Jesse Keating wrote:
> Treat the origin/F-?? as the master for that release, do your long
> running not immediately ready for build work on topic branches thereof
> and only merge them when you're ready to build.
This requires us to know in advance that the work will be long running. In
my experience, this is usually only noticed once the new version has been
imported (with the intent to build it right away), or even once it made it
to testing and got massive negative karma (after all, that's what testing is
for: as the name says, stuff there needs to get tested and can fail).
One case where I had to branch off an old build: I noticed on December 14
that the September 30 kde-plasma-networkmanagement snapshot had been pushed
only to F11 updates and not to F12, breaking the upgrade path. By then, the
F-12 branch had moved on to an October 24 snapshot, but I didn't want to
rush out a newer, untested snapshot to fix the upgrade path, but instead
queue the same one as on F11. (In addition, the October 24 snapshot is
outdated too, Rawhide has a newer one, but current snapshots require Qt
4.6.) But the corresponding F12 build had already been deleted by Koji, so I
had to branch and rebuild a new one. I used the "create a branch with a name
which looks like a build tag to the tag validator" hack and branched
kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that
branch.
Kevin Kofler
While I need to digest this a bit more, it really sounds like you're
trying to do waaaay to active development on /released/ Fedora branches,
eg a problem of your own creation.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:28 a.m.
On Sat, 19 Dec 2009 10:56:57 -0800
Jesse Keating <jkeating(a)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
9:31 p.m.
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
8:10 p.m.
On Sun, 2009-12-20 at 19:31 -0800, Jesse Keating wrote:
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.
This has been done. The way the ACLs now work, if you are a packager,
you can create branches in any package that start with "private-". This
makes it even easier to pass changes around as you can tell the
maintainer to pull from or merge from a private branch you've created.
Nobody should be able to create any branches that do not start with
"private-".
If we wanted to lock this down more, and only allow you to commit to a
private- branch only if you already have write access to some other
branch (F-12, master, EL-5, whatever) then I'll have to add more logic
to the ACL generation tool. But for now, I like the freedom we have.
We'll make sure that the buildsystem will not allow any official
(non-scratch) builds to happen from a private-* branch.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
8:59 p.m.
On 12/21/2009 06:10 PM, Jesse Keating wrote:
This has been done. The way the ACLs now work, if you are a
packager,
you can create branches in any package that start with "private-". This
makes it even easier to pass changes around as you can tell the
maintainer to pull from or merge from a private branch you've created.
Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
anyone could push into a branch that I'm trying to work with.
Also, I wasn't able to delete a branch that I had pushed -- not sure if
you meant to allow that.
Josh
7:02 a.m.
On Mon, 21 Dec 2009 18:59:53 -0800
Josh Stone <jistone(a)redhat.com> wrote:
On 12/21/2009 06:10 PM, Jesse Keating wrote:
> This has been done. The way the ACLs now work, if you are a
> packager, you can create branches in any package that start with
> "private-". This makes it even easier to pass changes around as
> you can tell the maintainer to pull from or merge from a private
> branch you've created.
Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
anyone could push into a branch that I'm trying to work with.
Good catch IMHO. My first thought also would be to separate the
branches the package (co-)maintainers create, and those that
every contributor can create to reduce conflicts. However, I would
try to make them distinguishable, e.g.:
private-foo
for branches where all people in the pkg ACLs can push to
private/${FAS_ACCOUNT}/*
for the "any contributor can push" branches
Having private-foo-baar for feature foo-bar and private-foo-bar for user
foo's bar branch could end up being quite confusing.
--
Hans Ulrich Niedermann
10:04 a.m.
On Tue, 2009-12-22 at 14:02 +0100, Hans Ulrich Niedermann wrote:
On Mon, 21 Dec 2009 18:59:53 -0800
Josh Stone <jistone(a)redhat.com> wrote:
> On 12/21/2009 06:10 PM, Jesse Keating wrote:
> > This has been done. The way the ACLs now work, if you are a
> > packager, you can create branches in any package that start with
> > "private-". This makes it even easier to pass changes around as
> > you can tell the maintainer to pull from or merge from a private
> > branch you've created.
>
> Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
> anyone could push into a branch that I'm trying to work with.
Good catch IMHO. My first thought also would be to separate the
branches the package (co-)maintainers create, and those that
every contributor can create to reduce conflicts. However, I would
try to make them distinguishable, e.g.:
private-foo
for branches where all people in the pkg ACLs can push to
private/${FAS_ACCOUNT}/*
for the "any contributor can push" branches
Having private-foo-baar for feature foo-bar and private-foo-bar for user
foo's bar branch could end up being quite confusing.
Having ACLs based on the username committing would take a fair amount of
hacking on the ACL tool, but not impossible.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:09 a.m.
On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote:
Perhaps this should be locked down to private-$USERNAME-*?
Otherwise,
anyone could push into a branch that I'm trying to work with.
Also, I wasn't able to delete a branch that I had pushed -- not sure if
you meant to allow that.
If the ACL system were to keep everybody in their own $username
namespace, no two people could collaborate on a single branch, which
kinda defeats the purpose of having the server side branch.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
10:41 a.m.
On 12/22/2009 08:09 AM, Jesse Keating wrote:
On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote:
> Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
> anyone could push into a branch that I'm trying to work with.
>
> Also, I wasn't able to delete a branch that I had pushed -- not sure if
> you meant to allow that.
If the ACL system were to keep everybody in their own $username
namespace, no two people could collaborate on a single branch, which
kinda defeats the purpose of having the server side branch.
Not entirely, as those two people could still pull from each other's
branches. Or as Hans said, some other namespace could be pushable for
the maintainers to collaborate on.
Either we trust that no packager will ever misbehave, or we need to lock
this down...
Josh
11:15 a.m.
On Tue, 2009-12-22 at 08:41 -0800, Josh Stone wrote:
On 12/22/2009 08:09 AM, Jesse Keating wrote:
> On Mon, 2009-12-21 at 18:59 -0800, Josh Stone wrote:
>> Perhaps this should be locked down to private-$USERNAME-*? Otherwise,
>> anyone could push into a branch that I'm trying to work with.
>>
>> Also, I wasn't able to delete a branch that I had pushed -- not sure if
>> you meant to allow that.
>
> If the ACL system were to keep everybody in their own $username
> namespace, no two people could collaborate on a single branch, which
> kinda defeats the purpose of having the server side branch.
Not entirely, as those two people could still pull from each other's
branches. Or as Hans said, some other namespace could be pushable for
the maintainers to collaborate on.
Either we trust that no packager will ever misbehave, or we need to lock
this down...
Josh
Since no official builds would be able to come from the private
branches, and since you can create other branches from other devel
points along the way, I think I'm going to fall on the side of "trust"
here, since we can relatively easily clean up from either mistakes or
malicious intent.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:45 a.m.
Jesse Keating wrote:
Nobody should be able to create any branches that do not start with
"private-".
I really don't see the point of this, why can't we just allow any branch
name that isn't a reserved name (master or F-[0-9]+)?
We'll make sure that the buildsystem will not allow any official
(non-scratch) builds to happen from a private-* branch.
And as I wrote before, I don't like this at all, it's a regression from our
current workflow and it defeats the point of the much-touted easy branching
with git.
Kevin Kofler
9:35 a.m.
On 12/22/09 2:45 AM, Kevin Kofler wrote:
Jesse Keating wrote:
> Nobody should be able to create any branches that do not start with
> "private-".
I really don't see the point of this, why can't we just allow any branch
name that isn't a reserved name (master or F-[0-9]+)?
> We'll make sure that the buildsystem will not allow any official
> (non-scratch) builds to happen from a private-* branch.
And as I wrote before, I don't like this at all, it's a regression from our
current workflow
Define "our". In my personal opinion, Jesse is spot-on, we should NOT
allow official builds from a private branch. That's just insane. Scratch
builds are fine. Official builds need to be from the main branch, or a
common non-private branch (such as the kernel has done for maintaining
both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). 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.
--
Jarod Wilson
jarod(a)redhat.com
9:37 a.m.
On Tue, 22 Dec 2009, Jarod Wilson wrote:
On 12/22/09 2:45 AM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> Nobody should be able to create any branches that do not start with
>> "private-".
>
> I really don't see the point of this, why can't we just allow any branch
> name that isn't a reserved name (master or F-[0-9]+)?
>
>> We'll make sure that the buildsystem will not allow any official
>> (non-scratch) builds to happen from a private-* branch.
>
> And as I wrote before, I don't like this at all, it's a regression from our
> current workflow
Define "our". In my personal opinion, Jesse is spot-on, we should NOT
allow official builds from a private branch. That's just insane. Scratch
builds are fine. Official builds need to be from the main branch, or a
common non-private branch (such as the kernel has done for maintaining
both e.g. 2.6.29 and 2.6.30 trees simultaneously for F10). 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.
FWIW - I agree with both jesse and jarod. Official builds are from main
branch. Anything built anywhere else will never be official.
-sv
9:34 a.m.
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
> FWIW - I agree with both jesse and jarod. Official builds are from main
> branch. Anything built anywhere else will never be official.
How about scratch builds?
What about them? Scratch builds are not official by definition. They
don't show up in repos, are only available for a couple weeks, etc.
josh
9:38 a.m.
On 12/23/2009 09:04 PM, Josh Boyer wrote:
On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
> On 12/22/2009 09:07 PM, Seth Vidal wrote:
>
>> FWIW - I agree with both jesse and jarod. Official builds are from main
>> branch. Anything built anywhere else will never be official.
>
> How about scratch builds?
What about them? Scratch builds are not official by definition. They
don't show up in repos, are only available for a couple weeks, etc.
The question was, are they ok to build from private branches? How does
this tie into
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
Rahul
10:45 a.m.
On Dec 23, 2009, at 7:38, Rahul Sundaram <sundaram(a)fedoraproject.org>
wrote:
On 12/23/2009 09:04 PM, Josh Boyer wrote:
> On Wed, Dec 23, 2009 at 08:50:11PM +0530, Rahul Sundaram wrote:
>> On 12/22/2009 09:07 PM, Seth Vidal wrote:
>>
>>> FWIW - I agree with both jesse and jarod. Official builds are
>>> from main
>>> branch. Anything built anywhere else will never be official.
>>
>> How about scratch builds?
>
> What about them? Scratch builds are not official by definition.
> They
> don't show up in repos, are only available for a couple weeks, etc.
The question was, are they ok to build from private branches?
Yes
How does
this tie into
http://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
It doesn't really.
--
jes
10:31 a.m.
On Dec 23, 2009, at 7:20, Rahul Sundaram <sundaram(a)fedoraproject.org>
wrote:
On 12/22/2009 09:07 PM, Seth Vidal wrote:
> FWIW - I agree with both jesse and jarod. Official builds are from
> main
> branch. Anything built anywhere else will never be official.
How about scratch builds?
Those can come from anywhere, even srpms for packages no enev in our
source control.
--
Jes
12:28 p.m.
Jarod Wilson wrote:
On 12/22/09 2:45 AM, Kevin Kofler wrote:
> And as I wrote before, I don't like this at all, it's a regression from
> our current workflow
Define "our".
"Our current workflow" = what Fedora's current CVS setup allows.
In my personal opinion, Jesse is spot-on, we should NOT allow
official
builds from a private branch. That's just insane. Scratch builds are fine.
Official builds need to be from the main branch, or a common non-private
branch (such as the kernel has done for maintaining both e.g. 2.6.29 and
2.6.30 trees simultaneously for F10).
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.
Kevin Kofler
2:21 p.m.
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-??
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:46 p.m.
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
example.
--
Jarod Wilson
jarod(a)redhat.com
3:17 p.m.
On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote:
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
example.
I understand the use case, I'm still not super keen on having official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
So this needs some more thinking, and discussion, which is happening
here, which is a good thing. Healthy debate is good, lets just endeavor
to keep it healthy (:
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:26 p.m.
----- "Jesse Keating" <jkeating(a)redhat.com> wrote:
On Wed, 2009-12-23 at 15:46 -0500, Jarod Wilson wrote:
> 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
> example.
>
I understand the use case, I'm still not super keen on having
official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something
and
don't realize that the real live code is actually on a branch.
+1
We used branches for a temporary setup recently and it got two people crazy looking for
the sources for the builds. They ended up starting from scratch because they couldn't
find it.
So this needs some more thinking, and discussion, which is happening
here, which is a good thing. Healthy debate is good, lets just
endeavor
to keep it healthy (:
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
4:23 p.m.
I understand the use case, I'm still not super keen on having
official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
Surely all previous builds will be easy to "discover" in koji and that will
tell you the exact commit id. AIUI there should be an automagic git tag
pushed by koji so that just directly in git alone it is trivial and
reliable to find the commit matching a given build. In git the idea of a
branch is not inherently a permanent thing, and only the ancestry graph of
a particular commit is truly meaningful as historical information. Just
the commit id of interest is what you need to ascertain whether it is the
head or ancestor of which branches at the time you ask the question.
Thanks,
Roland
4:32 p.m.
On Wed, 2009-12-23 at 14:23 -0800, Roland McGrath wrote:
> I understand the use case, I'm still not super keen on
having official
> built packages come out of a branch. Makes discovery somewhat
> difficult, and leads to problems if we have to bump+build something and
> don't realize that the real live code is actually on a branch.
Surely all previous builds will be easy to "discover" in koji and that will
tell you the exact commit id. AIUI there should be an automagic git tag
pushed by koji so that just directly in git alone it is trivial and
reliable to find the commit matching a given build. In git the idea of a
branch is not inherently a permanent thing, and only the ancestry graph of
a particular commit is truly meaningful as historical information. Just
the commit id of interest is what you need to ascertain whether it is the
head or ancestor of which branches at the time you ask the question.
Right, but when I as a releng person need to bump something in an
emergency or when a maintainer is out, I expect origin/master to be
"live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect
that I'd have to go hunting down where the commit hash for the previous
build came from, then try to discover which branch that commit hash
currently lives on, so that I can commit on top of it and keep going.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5:07 p.m.
Right, but when I as a releng person need to bump something in an
emergency or when a maintainer is out, I expect origin/master to be
"live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect
that I'd have to go hunting down where the commit hash for the previous
build came from, then try to discover which branch that commit hash
currently lives on, so that I can commit on top of it and keep going.
Ok. But, chances are that builds from branches are for temporary
situations (emergency updates while bigger updates are in testing, etc.)
and the circumstance where the obvious tip is not the same as the last
build will be rare.
My real point was that such situations will be entirely well-defined in a
mechanical sense. So it's always possible to automate an "F-n/master is
not an ancestor of most recent dist-fn build" check, make it autoflame
maintainers every day, etc.
Certainly I don't think that releng people should be expected to do commits
on random branches that maintainers happen to be using. I can't really
imagine that a maintainer really ever wants that. But once each of those
"go hunting down" and "try to discover" steps is entirely automated
with
100% reliably correct answers in an instant, as should certainly be quite
simple in git, then the picture of absolute necessity for a priori controls
on how maintainers do all their business looks a bit thinner. That's all.
Thanks,
Roland
10:32 p.m.
On 12/23/2009 06:07 PM, Roland McGrath wrote:
> Right, but when I as a releng person need to bump something in
an
> emergency or when a maintainer is out, I expect origin/master to be
> "live" for rawhide, ditto origin/F-12 for Fedora 12. I don't expect
> that I'd have to go hunting down where the commit hash for the previous
> build came from, then try to discover which branch that commit hash
> currently lives on, so that I can commit on top of it and keep going.
Ok. But, chances are that builds from branches are for temporary
situations (emergency updates while bigger updates are in testing, etc.)
and the circumstance where the obvious tip is not the same as the last
build will be rare.
Yeah, but in the situation where I need to make a quick legal change, I
would really prefer to know for sure where to make that change, and not
have to worry about which of the numerous branches I should apply it to.
~spot
3:11 a.m.
ons 2009-12-23 klockan 14:32 -0800 skrev Jesse Keating:
I don't expect
that I'd have to go hunting down where the commit hash for the previous
build came from, then try to discover which branch that commit hash
currently lives on, so that I can commit on top of it and keep going.
Automate it in fedpkg? "fedpkg checkout emacs F12 stable" or something.
/abo
9:49 a.m.
Jesse Keating wrote:
I understand the use case, I'm still not super keen on having
official
built packages come out of a branch. Makes discovery somewhat
difficult, and leads to problems if we have to bump+build something and
don't realize that the real live code is actually on a branch.
At least the kernel and KDE folks want this, that's a significant proportion
of Fedora in terms of LOC. For KDE, we've done the "temp revert" hack at
times, but IMHO that really sucks, this is what branches are for. It's
basically impossible to properly maintain a large project without doing
either temp reverts (yuck!) or branches (what we had hoped the switch to git
would make easier, not harder or outright impossible – our CVS setup allows
it, perhaps accidentally, but whether this was intended or not, it is being
used in the wild and a few of us rely on this in their workflow). One branch
per distro version is not enough.
Kevin Kofler
5228
days inactive
5235
days old
49 comments
17 participants
participants (17)
-
Alexander Boström -
Fernando Nasser -
Hans Ulrich Niedermann -
Jarod Wilson -
Jeff Garzik -
Jesse Keating -
Jesse Keating -
Jonathan Underwood -
Josh Boyer -
Josh Stone -
Kevin Kofler -
Rahul Sundaram -
Ray Strode -
Roland McGrath -
Seth Vidal -
Tim Lauridsen -
Tom Callaway