-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6
This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor.
[1] https://fedoraproject.org/wiki/Summer_coding_ideas_for_2013#Fedpkg:_Chain-bu...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 09:08 AM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes.
~tom
== Fedora Project
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 09:08 AM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes.
I don't really see how that would be any worse than the current situation where updates sometimes land in stable before their dependencies do (because Bodhi doesn't yet support listing other updates as dependencies).
On 10/04/13 07:58 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 09:08 AM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes.
I don't really see how that would be any worse than the current situation where updates sometimes land in stable before their dependencies do (because Bodhi doesn't yet support listing other updates as dependencies).
We've probably been round this roundabout before, but updates are supposed to be internally consistent. If an update to Package A also requires Package B to be updated, both packages should be submitted as a single update. You should not submit one update for A and one for B. When I catch these cases, I file negative feedback until the updates are corrected.
I think it might be possible for a sufficiently sophisticated version of the proposed mechanism to help the packager out with doing this, in fact: it could help you do a chain build and then submit an update containing the full chain/set of packages.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 05:34:48 PM EDT, Adam Williamson wrote:
On 10/04/13 07:58 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 10:59:03 AM EDT, Tom Callaway wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/10/2013 09:08 AM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
My only concern with this is that on non-Rawhide branches, these overrides are temporary. I'd hate for this to result in incomplete update pushes.
I don't really see how that would be any worse than the current situation where updates sometimes land in stable before their dependencies do (because Bodhi doesn't yet support listing other updates as dependencies).
We've probably been round this roundabout before, but updates are supposed to be internally consistent. If an update to Package A also requires Package B to be updated, both packages should be submitted as a single update. You should not submit one update for A and one for B. When I catch these cases, I file negative feedback until the updates are corrected.
The classic response to this is that it means that in order to produce an update, you must be a package owner for all packages in that set (or else a provenpackager).
As a hypothetical example, let's take openlmi-storage, which is a management tool that depends on blivet (which is the storage library provided by the anaconda project). I have a new version of openlmi-storage that depends on a new version of blivet. I am unlikely to be a co-owner of blivet. With our current policy, my choices are "find a provenpackager to submit all packages as a combined update" (often difficult and requires negotiation with every package in the set) or "submit my package and make sure to wait until all dependencies hit stable" (which is error-prone).
And we have the reverse problem as well. I can recall multiple situations where we introduced serious (and in one case, nearly catastrophic) regressions in the nss crypto library because it was bundled with a Firefox update. Firefox updates almost never even make it into the update-testing push before getting auto-karma into stable because of the high usage. So now we haven't gotten appropriate testing for all of the packages in the set.
I think it might be possible for a sufficiently sophisticated version of the proposed mechanism to help the packager out with doing this, in fact: it could help you do a chain build and then submit an update containing the full chain/set of packages.
I'd certainly be in favor of that. But as I said above, I don't see how what I originally proposed is functionally any worse than things are now. It's following the exact same process, just taking some of the needless drudgery out of it.
On Wednesday, April 10, 2013 09:08 PM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6
This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor.
I know the code quite well, as I implemented a fedpkg-like tool (also based on pyrpkg) for $dayjob, and I had sent a few patches to Jesse. (which reminds me I still have a couple that I never sent back!)
I also know the Bodhi code intimately, again because I deployed it at $dayjob (and that implied quite extensive patching to remove hardcoded Fedora assumptions).
However, I don't have commit permissions to fedpkg (but I do have them for Bodhi), and as such I wouldn't be able to ensure the changes actually get merged.
So I probably wouldn't be the best person to mentor either, but if a student is interested and nobody else wants to, I could eventually act as one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed 10 Apr 2013 01:19:49 PM EDT, Mathieu Bridon wrote:
On Wednesday, April 10, 2013 09:08 PM, Stephen Gallagher wrote:
Historically, chain-builds were only supported in the Rawhide branch because it was the only location that could auto-generate the buildroot.
However, the modern version of bodhi now supports allowing users to submit individual packages to the buildroot of any branch.
It would make life easier for a great many people if 'fedpkg chain-build' could gain the capability to automatically submit buildroot overrides on non-Rawhide branches.
I've opened an RFE on the upstream fedpkg project here: https://fedorahosted.org/fedpkg/ticket/6
This might make an excellent and highly-useful GSoC project. I've added it to the Summer Coding Ideas Page[1]. I'm not the best person to act as mentor, since I don't know the code, but I'd be okay acting as a backup mentor.
I know the code quite well, as I implemented a fedpkg-like tool (also based on pyrpkg) for $dayjob, and I had sent a few patches to Jesse. (which reminds me I still have a couple that I never sent back!)
I also know the Bodhi code intimately, again because I deployed it at $dayjob (and that implied quite extensive patching to remove hardcoded Fedora assumptions).
However, I don't have commit permissions to fedpkg (but I do have them for Bodhi), and as such I wouldn't be able to ensure the changes actually get merged.
So I probably wouldn't be the best person to mentor either, but if a student is interested and nobody else wants to, I could eventually act as one.
Frankly, you sound like the perfect person to be the primary mentor for this effort, if you're willing. Can I add you to the proposal page?