On Jun 22, 2009, at 12:01, Michael Schwendt <mschwe...@gmail.com> wrote:
On Sun, 21 Jun 2009 19:08:11 -0400, Dave wrote:
On Sun, Jun 21, 2009 at 04:56:07PM -0600, Nathanael D. Noblet wrote:
I *wish* it made a difference. I did an upgrade am an left with a
host
of fc10 packages because the fc11 ones weren't considered newer.
For example people with updates-testing enabled on fc10 got a
non-upgraded yum because the versions were the same (except for
fc10/fc11) and it stopped working because python went from 2.5 to
2.6.
That's messed up. We used to check just before release time that this
situation never occured.
^^^^^
No, that's not entirely true. The full story is from the book "What
sucks
about Fedora".
There used to be regular runs of the upgradecheck.py script from the
Fedora Extras era, which mailed the fedora-maintainers list (and later
fedora-devel list), and later the upgradecheckspam.py script which
mailed
package owners directly. That helped with getting upgrade problems
fixed, but it wasn't part of any release policy to make sure all
upgrade
path violations would have to get fixed.
Then with the switch to koji+bodhi a few package owners complained
loudly
about false positives that were caused by pending builds, which were
not
found in the master repo yet. A few other package owners jumped upon
the
train and questioned the usefulness of the script, since they were
of the
opinion that breaking upgrade paths the way they did it with updates-
testing
and stable updates would not be considered a problem.
Even later there used to be another script that queried koji for more
accurate package release versions, but it has never been run
regularly,
not even prior to the next Fedora release.
It should probably be added to the rel-eng
release checklist if it isn't there already.
Does rel-eng have any interest at all in avoiding some upgrade path
problems? I don't see that. Running a script to catch _some_ issues
would
be tons better than not running a script at all. The problem is not
limited to some people upgrading from F10 updates-testing to F11
without
updates-testing. There are still packagers who bump %version or
%release
in old dist updates without considering the consequences with regard
to
dist upgrades. And in Rawhide? Just because a packager doesn't track
Rawhide for some time should not imply that files in "devel" cvs
become
older than in the other dist branches or that updates for released
dists
get ahead of builds in Rawhide. The freeze only adds to the problem,
because packagers can push upgrades for old dists while the unreleased
dists remains frozen. It's also simply a crap decision if packagers
quickly mark F10 updates as stable while the corresponding F11
update has
not seen any testing at all (while it's stuck in the growing list of
pending updates in bodhi or waiting for release of F11).
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Releng and qa are interested in finding and fixing these issues.
Upgrade path issues will be a part of the autoqa system.
--
Jes
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
