I just did a "package-cleanup --orphans" on my Rawhide machine to see which of the just-blocked packages are installed there. To my surprise, I got this:
# package-cleanup --orphans Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit [snip stuff that I need to take care of] rpm-4.9.1-2.fc16.x86_64 rpm-build-4.9.1-2.fc16.x86_64 rpm-build-libs-4.9.1-2.fc16.x86_64 rpm-devel-4.9.1-2.fc16.x86_64 rpm-libs-4.9.1-2.fc16.x86_64 rpm-python-4.9.1-2.fc16.x86_64 # repoquery rpm rpm-0:4.9.0-10.fc16.x86_64
Was this intentional?
On Tue, 2011-07-26 at 13:59 -0600, Jerry James wrote:
I just did a "package-cleanup --orphans" on my Rawhide machine to see which of the just-blocked packages are installed there. To my surprise, I got this:
# package-cleanup --orphans Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit [snip stuff that I need to take care of] rpm-4.9.1-2.fc16.x86_64 rpm-build-4.9.1-2.fc16.x86_64 rpm-build-libs-4.9.1-2.fc16.x86_64 rpm-devel-4.9.1-2.fc16.x86_64 rpm-libs-4.9.1-2.fc16.x86_64 rpm-python-4.9.1-2.fc16.x86_64 # repoquery rpm rpm-0:4.9.0-10.fc16.x86_64
Was this intentional?
Yes, rpm-4.9.1 has seriously broken rpmbuild process.
On Tue, 26 Jul 2011 13:59:51 -0600, JJ (Jerry) wrote:
I just did a "package-cleanup --orphans" on my Rawhide machine to see which of the just-blocked packages are installed there. To my surprise, I got this:
# package-cleanup --orphans Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit [snip stuff that I need to take care of] rpm-4.9.1-2.fc16.x86_64 rpm-build-4.9.1-2.fc16.x86_64 rpm-build-libs-4.9.1-2.fc16.x86_64 rpm-devel-4.9.1-2.fc16.x86_64 rpm-libs-4.9.1-2.fc16.x86_64 rpm-python-4.9.1-2.fc16.x86_64 # repoquery rpm rpm-0:4.9.0-10.fc16.x86_64
Was this intentional?
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
On Tue, Jul 26, 2011 at 2:14 PM, Michael Schwendt mschwendt@gmail.com wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
Thanks for the replies, Tomas and Michael. I somehow missed the part where I needed to downgrade rpm.
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
On Tue, 2011-07-26 at 13:24 -0700, Jesse Keating wrote:
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
I do not think it was so hard rule for rawhide - it depended on various things whether it was needed or not.
On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote:
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
Yep. You are correct. If I'm doing proper forensics of fesco meeting notes and tickets and google searches of the wiki, this policy was approved twice by fesco but didn't get documented either time:
https://fedorahosted.org/fesco/ticket/96 http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313
The original proposal fell out of the no frozen rawhide FAD if I remember correctly.
-Toshio
On Tue, 26 Jul 2011 14:42:09 -0700, TK (Toshio) wrote:
On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote:
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
Yep. You are correct. If I'm doing proper forensics of fesco meeting notes and tickets and google searches of the wiki, this policy was approved twice by fesco but didn't get documented either time:
https://fedorahosted.org/fesco/ticket/96 http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313
The original proposal fell out of the no frozen rawhide FAD if I remember correctly.
Ticket 96 is very imprecise, unfortunately.
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
On Wed, 2011-07-27 at 11:03 +0200, Michael Schwendt wrote:
On Tue, 26 Jul 2011 14:42:09 -0700, TK (Toshio) wrote:
On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote:
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
Yep. You are correct. If I'm doing proper forensics of fesco meeting notes and tickets and google searches of the wiki, this policy was approved twice by fesco but didn't get documented either time:
https://fedorahosted.org/fesco/ticket/96 http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313
The original proposal fell out of the no frozen rawhide FAD if I remember correctly.
Ticket 96 is very imprecise, unfortunately.
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
+1, this should be only temporary breakage, although the fix is unfortunately not there yet.
On 7/27/11 2:03 AM, Michael Schwendt wrote:
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
If it goes backwards to await a fix, that fix needs to be happening within the same day or so. Not prolonged so that updates fail on users' systems.
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote:
On 7/27/11 2:03 AM, Michael Schwendt wrote:
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
If it goes backwards to await a fix, that fix needs to be happening within the same day or so.
Panu has mentioned that he will be looking into fixing this unexpected breakage. If that isn't acceptable to you, feel free to provide a fix faster.
Not prolonged so that updates fail on users' systems.
Do they fail in this case? Do you prefer rpm-build in koji buildroot to fail even longer? An issue with rpm-build on Rawhide installations is minor compared with Fedora's offical buildsys.
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds.
And in either case, I'm the wrong target of your flames.
On Wed, Jul 27, 2011 at 8:39 PM, Michael Schwendt mschwendt@gmail.com wrote:
On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote:
On 7/27/11 2:03 AM, Michael Schwendt wrote:
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
If it goes backwards to await a fix, that fix needs to be happening within the same day or so.
Panu has mentioned that he will be looking into fixing this unexpected breakage. If that isn't acceptable to you, feel free to provide a fix faster.
Not prolonged so that updates fail on users' systems.
Do they fail in this case? Do you prefer rpm-build in koji buildroot to fail even longer? An issue with rpm-build on Rawhide installations is minor compared with Fedora's offical buildsys.
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
The proper fix would have been to just use epoch. People can call them evil all they want they are perfectly suitable for that kind of problems.
On Wed, Jul 27, 2011 at 20:46:25 +0200, drago01 drago01@gmail.com wrote:
The proper fix would have been to just use epoch. People can call them evil all they want they are perfectly suitable for that kind of problems.
Or just rebuild the old version again. (Which should work unless something external to the package was causing problems.)
On Wed, 2011-07-27 at 20:39 +0200, Michael Schwendt wrote:
Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds.
And how would we stop that? by...encouraging people not to use it as a dumping ground. What's the best way to achieve that? Try and change the perception of it as a dumping ground...
On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:
On Wed, 2011-07-27 at 20:39 +0200, Michael Schwendt wrote:
Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds.
And how would we stop that? by...encouraging people not to use it as a dumping ground. What's the best way to achieve that? Try and change the perception of it as a dumping ground...
Communication, education, guidelines, policies. Start there?
Not even Fedora's official Wiki page is ''trying very hard to kill the notion that "rawhide may eat babies"'' (quoting Jesse).
http://fedoraproject.org/wiki/Releases/Rawhide
| End users should not use Rawhide as their main day-to-day workstation. | Because Rawhide is a development branch, many changes are not heavily | tested (or tested at all) before being released to Rawhide, and packages | in Rawhide can and do break without warning. It is even possible that | bugs in Rawhide could cause data loss.
On 07/28/2011 04:54 AM, Michael Schwendt wrote:
On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:
And how would we stop that? by...encouraging people not to use it as a dumping ground. What's the best way to achieve that? Try and change the perception of it as a dumping ground...
Communication, education, guidelines, policies. Start there?
Not even Fedora's official Wiki page is ''trying very hard to kill the notion that "rawhide may eat babies"'' (quoting Jesse).
Maybe a more nuanced logo, e.g.
"rawhide: tries hard to NOT eat babies"
On Thu, 2011-07-28 at 10:24 -0400, Przemek Klosowski wrote:
Maybe a more nuanced logo, e.g.
"rawhide: tries hard to NOT eat babies"
We could have one of those workplace accident signs - "Rawhide Hasn't Eaten A Baby For (XX) Days"...
On 07/27/2011 09:39 PM, Michael Schwendt wrote:
On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote:
On 7/27/11 2:03 AM, Michael Schwendt wrote:
There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed".
If it goes backwards to await a fix, that fix needs to be happening within the same day or so.
Panu has mentioned that he will be looking into fixing this unexpected breakage. If that isn't acceptable to you, feel free to provide a fix faster.
Rawhide now has rpm 4.9.1.1 which should fix the regressions. Apologies for taking so long with it, I didn't expect to be this busy AFK just like I did not expect such breakage with the 4.9.1 release.
If further breakage is spotted (I certainly hope not, but...), untag and ping ffesti and jnovy in addition to me.
Not prolonged so that updates fail on users' systems.
Do they fail in this case? Do you prefer rpm-build in koji buildroot to fail even longer? An issue with rpm-build on Rawhide installations is minor compared with Fedora's offical buildsys.
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds.
In this case, nobody's system was at risk of being eaten alive, these issues "only" affected rpmbuild. Obviously rpm generating buggy packages is bad enough as it affects everything and the world, but sometimes s*** just happens no matter how much testing gets done before a release.
- Panu -
On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
On 7/27/11 2:03 AM, Michael Schwendt wrote:
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
distro-sync also helps, and is a bit more generic.
We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive.
Sisyphean task ... IMO.
There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
But at some point you have to commit. You have to have a place all the updates go first, currently that's rawhide. It's been rawhide for ~20 years, it seems like a better idea for it to continue to be rawhide and just create a "tanned" repo. (or multiple ones) that eats less babies.
On 7/28/11 8:41 AM, James Antill wrote:
Sisyphean task ... IMO.
So was moving us off of CVS. *shrug*
There are multiple ways to throw
baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
But at some point you have to commit. You have to have a place all the updates go first, currently that's rawhide. It's been rawhide for ~20 years, it seems like a better idea for it to continue to be rawhide and just create a "tanned" repo. (or multiple ones) that eats less babies.
Actually the plan log ago was to involve AutoQA as a filter between "I built this package for rawhide" and "this build showed up in buildroots and the public rawhide repo".
At first the autoQA tests were going to be very simplistic, like "does it break every dep in the world", or things like that. It would also allow developers to manually override the test results and push a package anyway if they knew what they were doing. Then as that got mature we could start introducing package specific functional testing as well.
Since much of this rests on the shoulders of AutoQA, it is not surprising that it isn't documented much in the wiki.
On Thu, Jul 28, 2011 at 11:41:47AM -0400, James Antill wrote:
On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
On 7/27/11 2:03 AM, Michael Schwendt wrote:
In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build.
distro-sync also helps, and is a bit more generic.
We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive.
Sisyphean task ... IMO.
There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground.
But at some point you have to commit. You have to have a place all the updates go first, currently that's rawhide. It's been rawhide for ~20 years, it seems like a better idea for it to continue to be rawhide and just create a "tanned" repo. (or multiple ones) that eats less babies.
Raw Hide's only existed since 1998 [1], but anyway.
I'd lean more toward reminding package maintainers who put updates into Raw Hide that what they put there impacts everyone else who's trying to put updates into Raw Hide -- _one_ person breaking Raw Hide makes it harder for _all_ package maintainers to get things done.
I'm probably understating just how frustrating that is (for me, at least), but using harsher words would probably undermine my point.
Nalin
[1] http://www.redhat.com/about/news/prarchive/1998/press_rolling.html
On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
On 7/26/11 1:14 PM, Michael Schwendt wrote:
Yes, It got untagged. See last week's thread on this list: Subject: rpm builds failing with "Installed (but unpackaged) file(s) found"
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
I untagged the rpm build and we do have that rule, I could have sworn that it had only been built that day and not made it into rawhide. if i had realised that it had made it to rawhide i would have bumped the epoch on the old build to ensure that updating was correctly handled.
Dennis
On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
I untagged the rpm build and we do have that rule, I could have sworn that it had only been built that day and not made it into rawhide. if i had realised that it had made it to rawhide i would have bumped the epoch on the old build to ensure that updating was correctly handled.
Bumping epoch in rpm would have made it harder for all other packages to depend on a particular rpm version. Instead of having e.g. Requires: rpm >= 4.9.1, they would now also have to remember the put the correct epoch in there.
I think it's reasonable to have a broken package pulled from rawhide for a little while, if it's going to be properly fixed up in a few days. Yes, we should try to avoid such things, but having a hard rule here would be counter-productive.
Also, we have a much worse case of versions going backwards. After each Alpha release, lots of people are going to install Branched pre-releases and they automatically get enabled updates-testing repos. And in that updates-testing repo, packages are often pulled out and versions go backwards. Why is such practice allowed in Branched, but not in rawhide?
On Fri, 2011-07-29 at 02:29 +0300, Kalev Lember wrote:
On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
I thought there was a hard rule about not having nvrs go backwards, and if a bad build was put out, it should be fixed with epoch or other such NVR things to make sure the upgrade path continues. (that is once a build makes it out in the nightly repos)
I untagged the rpm build and we do have that rule, I could have sworn that it had only been built that day and not made it into rawhide. if i had realised that it had made it to rawhide i would have bumped the epoch on the old build to ensure that updating was correctly handled.
Bumping epoch in rpm would have made it harder for all other packages to depend on a particular rpm version. Instead of having e.g. Requires: rpm >= 4.9.1, they would now also have to remember the put the correct epoch in there.
I think it's reasonable to have a broken package pulled from rawhide for a little while, if it's going to be properly fixed up in a few days. Yes, we should try to avoid such things, but having a hard rule here would be counter-productive.
Also, we have a much worse case of versions going backwards. After each Alpha release, lots of people are going to install Branched pre-releases and they automatically get enabled updates-testing repos. And in that updates-testing repo, packages are often pulled out and versions go backwards. Why is such practice allowed in Branched, but not in rawhide?
Indeed; and remember we have yum distro-sync which fixes that problem quite nicely, I don't see why it shouldn't also work for quick reverts in Rawhide.
On Fri, 29 Jul 2011 02:29:23 +0300, KL (Kalev) wrote:
Bumping epoch in rpm would have made it harder for all other packages to depend on a particular rpm version. Instead of having e.g. Requires: rpm >= 4.9.1, they would now also have to remember the put the correct epoch in there.
Worth noting is that the rpm* packages currently are still without Epoch, and the second release of 4.9.1 has also been untagged a few days later. That would have resulted in a second Epoch bump then.
I think it's reasonable to have a broken package pulled from rawhide for a little while, if it's going to be properly fixed up in a few days. Yes, we should try to avoid such things, but having a hard rule here would be counter-productive.
Especially if the breakage didn't cause loss of data or severe damage on users' machines. Just rpm-build was affected, wasn't it?
Also, we have a much worse case of versions going backwards. After each Alpha release, lots of people are going to install Branched pre-releases and they automatically get enabled updates-testing repos. And in that updates-testing repo, packages are often pulled out and versions go backwards. Why is such practice allowed in Branched, but not in rawhide?
Good question, IMO. ;)
Kalev Lember wrote:
Bumping epoch in rpm would have made it harder for all other packages to depend on a particular rpm version. Instead of having e.g. Requires: rpm >= 4.9.1, they would now also have to remember the put the correct epoch in there.
Indeed, Epoch should be used only as a last resort, it's silly to force its usage this way!
I think we should go back to requiring monotonically increasing EVRs only for released versions, not Rawhide.
I think it's reasonable to have a broken package pulled from rawhide for a little while, if it's going to be properly fixed up in a few days. Yes, we should try to avoid such things, but having a hard rule here would be counter-productive.
+1
At the very least, let's not be anal about enforcing that rule, if we want it at all!
Also, we have a much worse case of versions going backwards. After each Alpha release, lots of people are going to install Branched pre-releases and they automatically get enabled updates-testing repos. And in that updates-testing repo, packages are often pulled out and versions go backwards. Why is such practice allowed in Branched, but not in rawhide?
Enabling updates-testing by default for Branched was a very stupid decision. This should be reverted. updates-testing should NEVER be enabled by default.
We should instead focus on getting stuff out to stable faster. In particular, why not allow direct stable pushes (without any karma) for branched-but-unreleased versions?
Kevin Kofler
On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
Enabling updates-testing by default for Branched was a very stupid decision. This should be reverted. updates-testing should NEVER be enabled by default.
We should instead focus on getting stuff out to stable faster. In particular, why not allow direct stable pushes (without any karma) for branched-but-unreleased versions?
+1
Simo.
On Wed, 2011-08-03 at 22:12 -0400, Simo Sorce wrote:
On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
Enabling updates-testing by default for Branched was a very stupid decision. This should be reverted. updates-testing should NEVER be enabled by default.
We should instead focus on getting stuff out to stable faster. In particular, why not allow direct stable pushes (without any karma) for branched-but-unreleased versions?
+1
+1 from me as well at least up to the beta release. Between beta to pre release I'd require just 1 karma from non-proventester for critical path.
On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
Also, we have a much worse case of versions going backwards. After each Alpha release, lots of people are going to install Branched pre-releases and they automatically get enabled updates-testing repos. And in that updates-testing repo, packages are often pulled out and versions go backwards. Why is such practice allowed in Branched, but not in rawhide?
Enabling updates-testing by default for Branched was a very stupid decision. This should be reverted. updates-testing should NEVER be enabled by default.
You don't make any attempt to engage with the reason for it: to ensure that updates get sufficient testing. I'm surprised you don't like this decision, since you're forever complaining about updates not getting karma fast enough. updates-testing is enabled for branched releases precisely to help updates get tested. If you want the policy to be changed, you should at least engage with why it is the way it is, and explain why you think the benefits of not enabling updates-testing by default in Branched releases (which, to me, seem marginal: it saves people who run pre-releases and then update to final a bit of trouble) outweigh the drawbacks (which, in the shape of reduced feedback on testing updates for Branched releases, could be significant).
We should instead focus on getting stuff out to stable faster. In particular, why not allow direct stable pushes (without any karma) for branched-but-unreleased versions?
Could you please stop getting up on this horse at every opportunity, even in extremely tangentially-related threads? Everyone's aware that you think this is what should happen. I don't see that you're getting anywhere just by bringing it up at every possible opportunity.
On 08/03/2011 10:14 PM, Adam Williamson wrote:
On Thu, 2011-08-04 at 03:53 +0200, Kevin Kofler wrote:
We should instead focus on getting stuff out to stable faster. In particular, why not allow direct stable pushes (without any karma) for branched-but-unreleased versions?
Could you please stop getting up on this horse at every opportunity, even in extremely tangentially-related threads? Everyone's aware that you think this is what should happen. I don't see that you're getting anywhere just by bringing it up at every possible opportunity.
He's just doing a Cato: "Ceterum censeo pulsae stabile permitteret sine karma" :)
Adam Williamson wrote:
You don't make any attempt to engage with the reason for it: to ensure that updates get sufficient testing.
I kinda did, with the next paragraph (which you are quick to dismiss as off topic). :-)
People will test the stuff when it's marked stable, and that way they actually test what will be in the release (or the Alpha or Beta).
changed, you should at least engage with why it is the way it is, and explain why you think the benefits of not enabling updates-testing by default in Branched releases (which, to me, seem marginal: it saves people who run pre-releases and then update to final a bit of trouble) outweigh the drawbacks (which, in the shape of reduced feedback on testing updates for Branched releases, could be significant).
1. I don't consider the upgrade path issue "marginal" at all. If people install our prereleases, they expect to be able to upgrade to the final release seamlessly. At each release, we get bug reports about "broken upgrade paths" from Beta to Final which are actually just a result of updates-testing getting magically disabled (and keeping it enabled wouldn't be that great a solution either). 2. Updates-testing tends to contain very broken stuff, for which the maintainer knows it needs more testing before being proven usable (or not). Enabling it by default makes Branched more unstable than it could be (and in some cases, even more unstable than Rawhide, as the EVR monotonicity issue which is the subject of this thread shows). 3. People testing with updates-testing enabled aren't testing what will actually end up in the releases (Alpha, Beta, Final), which use only packages marked stable. 4. Updates-testing being enabled by default means that people installing an Alpha or Beta immediately get fed tons of 0-day (actually negative-day) updates, because the Alpha or Beta does not include those testing updates by design. It makes it look quite pointless to work on stabilizing the Beta when people who installed the Alpha and ran "yum update" are already using newer packages than those the Beta will ship before the Beta is even being prepared. 5. People who want to use updates-testing will opt in to it explicitly. Opting in is easier than opting out because it means upgrading packages rather than downgrading them.
Kevin Kofler
On Fri, 2011-08-05 at 05:10 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
You don't make any attempt to engage with the reason for it: to ensure that updates get sufficient testing.
I kinda did, with the next paragraph (which you are quick to dismiss as off topic). :-)
People will test the stuff when it's marked stable, and that way they actually test what will be in the release (or the Alpha or Beta).
That's ass backwards, though. We need the testing _to determine if the things should be in the release_. Really, I think if you look at the quality of the releases that have happened since this policy was changed, it's pretty clear that it helps. It makes pulling together the pre-releases a lot less chaotic.
changed, you should at least engage with why it is the way it is, and explain why you think the benefits of not enabling updates-testing by default in Branched releases (which, to me, seem marginal: it saves people who run pre-releases and then update to final a bit of trouble) outweigh the drawbacks (which, in the shape of reduced feedback on testing updates for Branched releases, could be significant).
- I don't consider the upgrade path issue "marginal" at all. If people
install our prereleases, they expect to be able to upgrade to the final release seamlessly.
We're very clear about what you get to expect with pre-releases, and being able to upgrade to the final release seamlessly certainly isn't one of those things.
At each release, we get bug reports about "broken upgrade paths" from Beta to Final which are actually just a result of updates-testing getting magically disabled (and keeping it enabled wouldn't be that great a solution either).
Sure. I don't see that as a huge issue. We explain why it happens and provide the solution - distro-sync - and people are generally fine with that. I haven't seen anyone who thought it was a terrible idea yet.
- Updates-testing tends to contain very broken stuff, for which the
maintainer knows it needs more testing before being proven usable (or not).
One, that's certainly not how updates-testing is supposed to work, and two, I dispute that it's the case in practice. Could you point to an example?
Enabling it by default makes Branched more unstable than it could be (and in some cases, even more unstable than Rawhide, as the EVR monotonicity issue which is the subject of this thread shows).
Erm, the update in this thread happened in Rawhide; F16 was not branched at the time. If F16 had been branched, the update would never have made it out of updates-testing, hence much less of a problem. Making it less likely that we'll have to do reversions / epoch bumps is one of the *strengths* of the updates-testing system.
- People testing with updates-testing enabled aren't testing what will
actually end up in the releases (Alpha, Beta, Final), which use only packages marked stable.
Sure. But their testing enables us to make good decisions about what *should* go into the release. I don't see where this is a problem.
- Updates-testing being enabled by default means that people installing an
Alpha or Beta immediately get fed tons of 0-day (actually negative-day) updates, because the Alpha or Beta does not include those testing updates by design. It makes it look quite pointless to work on stabilizing the Beta when people who installed the Alpha and ran "yum update" are already using newer packages than those the Beta will ship before the Beta is even being prepared.
It's not at all pointless, because the point of the Alpha / Beta images is to provide a known-good base. If the Alpha / Beta are broken, you're pretty screwed. If an update is broken, just re-install from the known-good base and skip the update.
Looks like I forgot to reply to this:
Adam Williamson wrote:
That's ass backwards, though. We need the testing _to determine if the things should be in the release_. Really, I think if you look at the quality of the releases that have happened since this policy was changed, it's pretty clear that it helps. It makes pulling together the pre-releases a lot less chaotic.
I'm not convinced… Our previous releases were quite good too!
We're very clear about what you get to expect with pre-releases, and being able to upgrade to the final release seamlessly certainly isn't one of those things.
And I think this is both extremely unhelpful and a total disconnect from user expectations.
Sure. I don't see that as a huge issue. We explain why it happens and provide the solution - distro-sync - and people are generally fine with that. I haven't seen anyone who thought it was a terrible idea yet.
Well, now you've seen one. :-)
(And the solution I actually give is: "Try 'yum distro-sync' this time, and next time you install a prerelease, you'll probably want to make sure you disable updates-testing before doing anything else, in particular before installing ANY update…")
- Updates-testing tends to contain very broken stuff, for which the
maintainer knows it needs more testing before being proven usable (or not).
One, that's certainly not how updates-testing is supposed to work, and
What is it for then, if not for testing things to see whether they work or not? That really SHOULD be how updates-testing SHOULD work. If the maintainer knows that an update works, it should be in stable, not testing (which also means the maintainer should be the one making that decision, not some arbitrary policy…).
two, I dispute that it's the case in practice. Could you point to an example?
For how updates-testing works out in practice, just look at any package with negative karma. Now, there's some probability that it's one of those packages where the karma system just didn't work (you cannot just sum all +1 and -1 comments and expect it to sum to something meaningful, building automatically enforced policies out of this totally arbitrary number just makes no sense), but still, in many cases, the negative karma is there for a good reason.
Enabling it by default makes Branched more unstable than it could be (and in some cases, even more unstable than Rawhide, as the EVR monotonicity issue which is the subject of this thread shows).
Erm, the update in this thread happened in Rawhide; F16 was not branched at the time. If F16 had been branched, the update would never have made it out of updates-testing, hence much less of a problem.
Except that updates-testing is enabled by default! Which, incidentally, is exactly what I'm complaining about.
I think you're missing my point:
Making it less likely that we'll have to do reversions / epoch bumps is one of the *strengths* of the updates-testing system.
Only for those users NOT using updates-testing.
Updates can be pulled out of updates-testing at any moment, which makes a lot of sense, but which means that users with updates-testing enabled will end up with the EVR going backwards, something that's not even allowed in Rawhide.
Enabling updates-testing by default means forcing EVR downgrades on users of Branched by default, making the policy banning them in Rawhide totally pointless.
- People testing with updates-testing enabled aren't testing what will
actually end up in the releases (Alpha, Beta, Final), which use only packages marked stable.
Sure. But their testing enables us to make good decisions about what *should* go into the release. I don't see where this is a problem.
The problem is that basically nobody is testing the actual release package set, considering that it's much less straightforward to opt out of updates- testing than to opt in, and that probably only few people are doing it (and those who do bother to explicitly opt out of updates-testing are the ones who just need early access to the releases for whatever reason, e.g. because they need a newer version of some package, and don't actually want to do any testing whatsoever, just to seamlessly move on to the release when it's out officially).
It's not at all pointless, because the point of the Alpha / Beta images is to provide a known-good base. If the Alpha / Beta are broken, you're pretty screwed. If an update is broken, just re-install from the known-good base and skip the update.
LOL, good luck finding the offending update among the dozens of packages which will get upgraded in your first update after installing the Alpha or Beta.
Oh, and this wouldn't be any different if we changed the policy anyway,
Not true:
Consider the following sets of updates: * Set A of updates goes stable before the freeze. * Set B of updates goes to testing before the freeze, gets queued for stable during the freeze and pushed right after the unfreeze. * Set C of updates goes to testing during the freeze, gets queued for stable during the freeze and pushed right after the unfreeze. * Set D of updates goes to testing during the freeze (or right after the unfreeze, in the same push where sets B and C go stable) and gets queued for and pushed to stable only well after the unfreeze. * Set E of updates goes to testing well after the unfreeze.
The compose obviously includes only update set A.
Assume we are right after the unfreeze: * Update sets A, B and C are stable. * Update set D is in updates-testing. * Update set E is not queued anywhere yet (probably not even built yet).
Current: The user will get offered update sets B, C and D as updates. Proposed: The user will get offered only update sets B and C as updates.
This would reduce the number of 0-day updates for Alpha/Beta releases significantly.
Kevin Kofler
On 2011-08-19 20:41, Kevin Kofler wrote:
Updates can be pulled out of updates-testing at any moment, which makes a lot of sense, but which means that users with updates-testing enabled will end up with the EVR going backwards, something that's not even allowed in Rawhide.
Enabling updates-testing by default means forcing EVR downgrades on users of Branched by default, making the policy banning them in Rawhide totally pointless.
The problem is that basically nobody is testing the actual release package set, considering that it's much less straightforward to opt out of updates- testing than to opt in, and that probably only few people are doing it (and those who do bother to explicitly opt out of updates-testing are the ones who just need early access to the releases for whatever reason, e.g. because they need a newer version of some package, and don't actually want to do any testing whatsoever, just to seamlessly move on to the release when it's out officially).
FESCo discussed both of these issues before the release of the Fedora 15 Alpha at its meetings on 16 Feb 2011 and 2 Mar 2011. The current recommendation [1] is to run ``yum distro-sync'' after upgrading from pre-releases to the final release.
[1] https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final#After_upd...
On Thu, 2011-08-04 at 22:17 -0700, Adam Williamson wrote:
- Updates-testing being enabled by default means that people installing an
Alpha or Beta immediately get fed tons of 0-day (actually negative-day) updates, because the Alpha or Beta does not include those testing updates by design. It makes it look quite pointless to work on stabilizing the Beta when people who installed the Alpha and ran "yum update" are already using newer packages than those the Beta will ship before the Beta is even being prepared.
It's not at all pointless, because the point of the Alpha / Beta images is to provide a known-good base. If the Alpha / Beta are broken, you're pretty screwed. If an update is broken, just re-install from the known-good base and skip the update.
Oh, and this wouldn't be any different if we changed the policy anyway, because we'd still need to freeze to have any chance of building a usable Alpha or Beta release. So either no-one would get to do any work during the freeze unless it fixed a blocker/NTH issue, or we'd build the Alpha / Beta from the 'release' repo and not include packages in the 'update' repo, which would lead to exactly the same thing: after installing Alpha you'd have a ton of 0-day packages in updates which wouldn't have been tested as part of Alpha validation.
devel@lists.stg.fedoraproject.org