If I haven't missed something, it looks like there was only a 2-day window (during a weekend) between the update to fedora-release-13-1 (which enabled updates and disabled updates-testing)
http://lists.fedoraproject.org/pipermail/test/2010-May/090747.html
and the next push to updates-testing
http://lists.fedoraproject.org/pipermail/test/2010-May/090835.html
and I can't find any public mention of this (though I know it was mentioned somewhere). This is crucial information for anyone installing from an image from before around May 8 (such as the Beta). If they miss the window, and then don't update fedora-release first, they end up with probably unwanted updates-testing packages.
Just wondering, would it be possible and reasonable to have a flag associated with package updates that enable/disable repos, so that when an update includes them, do only those, and then notify that enabled repos have changed, so that another update should be done (or do it automatically)?
If not, I think these windows should be publicized better, so people installing from earlier images don't end up with unwanted packages on their system. For example, since the Alpha and Beta are announced on the announce list, that might be a good place to announce this window as well.
On Mon, 2010-05-17 at 14:50 -0400, Andre Robatino wrote:
If I haven't missed something, it looks like there was only a 2-day window (during a weekend) between the update to fedora-release-13-1 (which enabled updates and disabled updates-testing)
http://lists.fedoraproject.org/pipermail/test/2010-May/090747.html
and the next push to updates-testing
http://lists.fedoraproject.org/pipermail/test/2010-May/090835.html
and I can't find any public mention of this (though I know it was mentioned somewhere). This is crucial information for anyone installing from an image from before around May 8 (such as the Beta). If they miss the window, and then don't update fedora-release first, they end up with probably unwanted updates-testing packages.
Just wondering, would it be possible and reasonable to have a flag associated with package updates that enable/disable repos, so that when an update includes them, do only those, and then notify that enabled repos have changed, so that another update should be done (or do it automatically)?
If not, I think these windows should be publicized better, so people installing from earlier images don't end up with unwanted packages on their system. For example, since the Alpha and Beta are announced on the announce list, that might be a good place to announce this window as well.
The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity...
Adam Williamson <awilliam <at> redhat.com> writes:
The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity...
Confirmed - running "yum list extras" on my F13 guest, I got a very long list of updates-testing packages, even though I updated within the window. Doing yum downgrade on each of these packages seems to work fine, so one way to deal with problems caused by this (I'm thinking of dependency problems when installing/updating) would be to just downgrade packages as needed. However, I decided to reinstall instead, and make sure updates-testing was disabled before updating.
Adam Williamson wrote:
The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity...
Yes, the broken decision was to enable updates-testing by default for prereleases and we should never do this again. It just can't work, because updates-testing is like the Red Pill: once you're on it, you can't get off anymore. The fedora-release update which disabled updates-testing broke many user setups, suddenly unable to install packages due to dependencies.
Kevin Kofler
On Wed, 2010-05-19 at 00:24 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity...
Yes, the broken decision was to enable updates-testing by default for prereleases and we should never do this again. It just can't work, because updates-testing is like the Red Pill: once you're on it, you can't get off anymore. The fedora-release update which disabled updates-testing broke many user setups, suddenly unable to install packages due to dependencies.
Pre-release users, you mean. Who ought to be ready to deal with this sort of thing, or else they shouldn't be installing pre-releases. Full refunds available, etc. I'm not horribly bothered about it, really, now we know it happens and can spot the symptoms.
(and you can get off it, you can just search for packages from updates-testing and yum downgrade 'em. Wouldn't be too hard for someone to hack up a little script to do this and publish it somewhere, if they were terribly worried about this issue).
In practice it shouldn't be a hugely horrible problem after a few days/weeks, as most of the updates will get pushed or superseded.
On 05/19/2010 04:20 AM, Adam Williamson wrote:
On Wed, 2010-05-19 at 00:24 +0200, Kevin Kofler wrote:
Yes, the broken decision was to enable updates-testing by default for prereleases and we should never do this again. It just can't work, because updates-testing is like the Red Pill: once you're on it, you can't get off anymore. The fedora-release update which disabled updates-testing broke many user setups, suddenly unable to install packages due to dependencies.
Pre-release users, you mean. Who ought to be ready to deal with this sort of thing, or else they shouldn't be installing pre-releases. Full refunds available, etc. I'm not horribly bothered about it, really, now we know it happens and can spot the symptoms.
While I understand the decision behind enabling updates-testing repo by default, I think it should be turned off much earlier, perhaps during the beta release phase. Due to the workflow I follow, one of the problems of having it enabled by default till very late in the release cycle is that once I get the update running on my system, I sometimes forgot to push the update from updates-testing to updates repo for some of the packages I maintain. That was partially the reason why a major deja-dup update didn't go in sooner.
Rahul
On Tue, May 18, 2010 at 3:00 PM, Rahul Sundaram metherid@gmail.com wrote:
While I understand the decision behind enabling updates-testing repo by default, I think it should be turned off much earlier, perhaps during the beta release phase. Due to the workflow I follow, one of the problems of having it enabled by default till very late in the release cycle is that once I get the update running on my system, I sometimes forgot to push the update from updates-testing to updates repo for some of the packages I maintain. That was partially the reason why a major deja-dup update didn't go in sooner.
I'm not sure how turning updates-testing off sooner is going to help you remember to push to stable ahead of a deadline. You'd be personally running your own updates-testing builds on your personal systems regardless of whether updates-testing is on by default or not..aren't you? Can you explain your workflow in more detail? This seems like completely separate issues to me.
For me the only thing that's really going to help me be more aware of an rc freeze deadline and to push things to stable instead of letting them sit in testing is some proactive and repeated nagging from bodhi about my packages sitting in testing ahead of a freeze deadline to remind me to consider doing a stable push. I'm already relying on the bodhi nag emails about testing packages as a backstop when there's not enough karma to automate a push..but the timing of those reminders aren't pre-release freeze deadline aware. Have you been relying on reminders from bodhi about old testing updates to fire off stable pushes as part of your current workflow?
-jef
On Tue, 2010-05-18 at 23:50 +0100, Adam Williamson wrote:
On Wed, 2010-05-19 at 00:24 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
The window doesn't matter that much anyway, as by no means all packages pushed to updates-testing during the pre-final cycle have been (or will be) approved as updates. So it's perfectly possible people who installed pre-releases will have what you term 'unwanted' packages anyway. This seems to be to be reasonable for those who run pre-releases, but I suppose we could write it up somewhere for clarity...
Yes, the broken decision was to enable updates-testing by default for prereleases and we should never do this again. It just can't work, because updates-testing is like the Red Pill: once you're on it, you can't get off anymore. The fedora-release update which disabled updates-testing broke many user setups, suddenly unable to install packages due to dependencies.
[...]
(and you can get off it, you can just search for packages from updates-testing and yum downgrade 'em. Wouldn't be too hard for someone to hack up a little script to do this and publish it somewhere, if they were terribly worried about this issue).
For the rawhide yum (pre 3.2.28) you can just do:
yum distro-sync
...this will downgrade everything to the latest available version (or try). This doesn't work over obsoletes, due to their one way nature, but should be good enough for most "updates-testing downgrades".
In practice it shouldn't be a hugely horrible problem after a few days/weeks, as most of the updates will get pushed or superseded.
That too, one advantage of the firehose is it will make you clean pretty quickly ;)
-
Adam Williamson -
Andre Robatino -
James Antill -
Jef Spaleta -
Kevin Kofler -
Rahul Sundaram