Re: Why do we need FC version attached to the package name?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Jun 22, 2009, at 12:01, Michael Schwendt <mschwendt@xxxxxxxxx> 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@xxxxxxxxxx
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux