Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 23, 2009, at 7:20, Rahul Sundaram sunda...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 23, 2009, at 7:38, Rahul Sundaram sunda...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Mon, 21 Dec 2009 18:59:53 -0800
Josh Stone jist...@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
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Tue, 2009-12-22 at 14:02 +0100, Hans Ulrich Niedermann wrote:
On Mon, 21 Dec 2009 18:59:53 -0800
Josh Stone jist...@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
signature.asc
Description: This is a digitally signed message part
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
2009/12/21 Jesse Keating jkeat...@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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 wy 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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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
Re: dist-git proof of concept phase 2 ready for testing
On Sat, 19 Dec 2009 10:56:57 -0800 Jesse Keating jkeat...@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://n...@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://n...@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 signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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://[fedoraacco...@]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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
2009/12/18 Jesse Keating jkeat...@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://[fedoraacco...@]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 ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
2009/12/19 Jonathan Underwood jonathan.underw...@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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 8:42, Jonathan Underwood jonathan.underw...@gmail.com wrote: 2009/12/18 Jesse Keating jkeat...@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://[fedoraacco...@]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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
Hi, On Fri, Dec 18, 2009 at 6:31 PM, Jesse Keating jkeat...@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://[fedoraacco...@]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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
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://rstr...@pkgs.stg.fedoraproject.org/plymouth ! [remote rejected] private-topic-branch - private-topic-branch (hook declined) error: failed to push some refs to 'ssh://rstr...@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
Re: dist-git proof of concept phase 2 ready for testing
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
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@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
Re: dist-git proof of concept phase 2 ready for testing
On 12/19/2009 08:04 PM, Jesse Keating wrote: On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@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
dist-git proof of concept phase 2 ready for testing
Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]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 signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Fri, 18 Dec 2009 15:31:49 -0800 Jesse Keating jkeat...@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://[fedoraacco...@]pkgs.fedoraproject.org/package git clone ssh://[fedoraacco...@]pkgs.stg.fedoraproject.org/package as far as I can tell. -- Hans Ulrich Niedermann signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 18, 2009, at 16:37, Hans Ulrich Niedermann h...@n- dimensional.de wrote: On Fri, 18 Dec 2009 15:31:49 -0800 Jesse Keating jkeat...@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://[fedoraacco...@]pkgs.fedoraproject.org/package git clone ssh://[fedoraacco...@]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-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
