Hi! Some time ago I built new openarena package. Unfortunately, after some testing it turned out that package is broken and prevent players from playing multiplayer. It seems to me that package is built but it's not been pushed to repo yet. That's why I ask to remove it from rawhide. I know I could reverse all changes and bump release once again, but it will cause completely unnecessary update for some users. So since it's not in repo yet, I make a request to any admin to just preclude a package from being pushed to repo. I hope nothing stands in the way to do so.
On 01/06/2008 06:13 PM, � wrote:
Hi! Some time ago I built new openarena package. Unfortunately, after some testing it turned out that package is broken and prevent players from playing multiplayer. It seems to me that package is built but it's not been pushed to repo yet. That's why I ask to remove it from rawhide. I know I could reverse all changes and bump release once again, but it will cause completely unnecessary update for some users. So since it's not in repo yet, I make a request to any admin to just preclude a package from being pushed to repo. I hope nothing stands in the way to do so.
You can do this yourself, actually.
koji untag-pkg dist-f9 foo-1.2-3.fc9
It seems openarena has been untagged successfully. Christopher, thanks for advice!
2008/1/6, Christopher Aillon caillon@redhat.com:
On 01/06/2008 06:13 PM, � wrote:
Hi! Some time ago I built new openarena package. Unfortunately, after some testing it turned out that package is broken and prevent players from playing multiplayer. It seems to me that package is built but it's not been pushed to repo yet. That's why I ask to remove it from rawhide. I know I could reverse all changes and bump release once again, but it will cause completely unnecessary update for some users. So since it's not in repo yet, I make a request to any admin to just preclude a package from being pushed to repo. I hope nothing stands in the way to do so.
You can do this yourself, actually.
koji untag-pkg dist-f9 foo-1.2-3.fc9
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, 6 Jan 2008 18:26:33 +0100 "Michał Bentkowski" mr.ecik@gmail.com wrote:
It seems openarena has been untagged successfully. Christopher, thanks for advice!
Hrm. Some time ago we had agreed to not fix things by making builds disappear, even in rawhide. NVRs must always go up. Since doing this means anybody who happened to upgrade to your bad build, there is no way for them to get a fixed build unless they download the package manually and use a cryptic rpm call. The proper procedure would have been to back out the changes and bump the build so that there is an upgrade path.
On 01/06/2008 07:33 PM, Jesse Keating wrote:
On Sun, 6 Jan 2008 18:26:33 +0100 "Michał Bentkowski" mr.ecik@gmail.com wrote:
It seems openarena has been untagged successfully. Christopher, thanks for advice!
Hrm. Some time ago we had agreed to not fix things by making builds disappear, even in rawhide. NVRs must always go up. Since doing this means anybody who happened to upgrade to your bad build, there is no way for them to get a fixed build unless they download the package manually and use a cryptic rpm call. The proper procedure would have been to back out the changes and bump the build so that there is an upgrade path.
Even if he'd *just* built it into rawhide and it wouldn't have been in a compose yet? Someone would have had to grab it out of koji and use an rpm call to install it.
On Sun, 06 Jan 2008 20:04:08 +0100 Christopher Aillon caillon@redhat.com wrote:
Even if he'd *just* built it into rawhide and it wouldn't have been in a compose yet? Someone would have had to grab it out of koji and use an rpm call to install it.
Sure if it hadn't made a rawhide compose yet that's one thing. However he said "some time ago" which in my mind equals more than a day ago.
On 01/06/2008 08:22 PM, Jesse Keating wrote:
On Sun, 06 Jan 2008 20:04:08 +0100 Christopher Aillon caillon@redhat.com wrote:
Even if he'd *just* built it into rawhide and it wouldn't have been in a compose yet? Someone would have had to grab it out of koji and use an rpm call to install it.
Sure if it hadn't made a rawhide compose yet that's one thing. However he said "some time ago" which in my mind equals more than a day ago.
Yeah. I'm guessing he isn't a native speaker. FWIW, I looked to see what the latest build and builddate was before offering the advice. I probably should have also given the caveat though so others wouldn't have taken it as "the" solution.
Le Dim 6 janvier 2008 20:04, Christopher Aillon a écrit :
On 01/06/2008 07:33 PM, Jesse Keating wrote:
On Sun, 6 Jan 2008 18:26:33 +0100 "Michał Bentkowski" mr.ecik@gmail.com wrote:
It seems openarena has been untagged successfully. Christopher, thanks for advice!
Hrm. Some time ago we had agreed to not fix things by making builds disappear, even in rawhide. NVRs must always go up. Since doing this means anybody who happened to upgrade to your bad build, there is no way for them to get a fixed build unless they download the package manually and use a cryptic rpm call. The proper procedure would have been to back out the changes and bump the build so that there is an upgrade path.
Even if he'd *just* built it into rawhide and it wouldn't have been in a compose yet? Someone would have had to grab it out of koji and use an rpm call to install it.
Which happens all the time. Please consider that except for scratch builds, anything done in koji will end up on unsuspecting tester systems
Regards,
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
Which happens all the time. Please consider that except for scratch builds, anything done in koji will end up on unsuspecting tester systems
But if you fetch things from Koji yourself, you're responsible for the mess you're causing.
I fetch things from Koji sometimes (dist-f8-updates-candidate normally, I'm not running Rawhide), but never without a reason and I can deal with reverting to the latest official update when needed.
Kevin Kofler
Le Lun 7 janvier 2008 10:43, Kevin Kofler a écrit :
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
Which happens all the time. Please consider that except for scratch builds, anything done in koji will end up on unsuspecting tester systems
But if you fetch things from Koji yourself, you're responsible for the mess you're causing.
The question is not "how can I lay the blame on someone" the question is "how can I build trust in our devel publishing system so we get more testers and hopefully identify problems before final releases".
Koji is public. You can't safely doctor koji history anymore than you can doctor a public VCS. If you want to test stuff privately you have scratch builds. Otherwise fixing a bad build is just a version bump away.
Blaming testers for doing badly needed testing work, and making their life harder, is not helpful.
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
Koji is public. You can't safely doctor koji history anymore than you can doctor a public VCS. If you want to test stuff privately you have scratch builds. Otherwise fixing a bad build is just a version bump away.
Oh, there's a lot of doctoring which can be done. My personal favorite is "make force-tag". :-) If you screw up and the build fails, commit the fix, make force-tag, then resubmit the build in Koji and most traces of the botched build will vanish. ;-) (There'll be a hidden task somewhere in Koji and an untagged CVS commit and that's all.)
Kevin Kofler
Le Lun 7 janvier 2008 11:27, Kevin Kofler a écrit :
Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
Koji is public. You can't safely doctor koji history anymore than you can doctor a public VCS. If you want to test stuff privately you have scratch builds. Otherwise fixing a bad build is just a version bump away.
Oh, there's a lot of doctoring which can be done. My personal favorite is "make force-tag". :-) If you screw up and the build fails,
This is ugly but safe since no build was exposed to users, unlike the present case.
-
Christopher Aillon -
Jesse Keating -
Kevin Kofler -
Michał Bentkowski -
Nicolas Mailhot