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

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

 



Michael Schwendt wrote:
> 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.

The actual issue we complained about was that the script (the one querying
Koji) required Fn+1 updates to be >= Fn updates-testing which makes no
sense at all. I wrote a patch to fix that:
http://repo.calcforge.org/f10/check-upgrade-paths.py.diff
but it got lost under Jesse Keating's endless pile of TODOs. :-( And it
seems the whole code is going to be rewritten for autoqa now and nobody
cares about having a working check-upgrade-paths.py until autoqa goes
live. :-(

> 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).

In my experience, an update which is working fine on one release has a very
high probability of working just as well on the other ones, especially if
the package being updated was working in the first place (which are the
cases we really care about - if the package was broken, pushing an update
which is broken the same way doesn't make things worse). In the updates I
pushed, I only remember one case where it didn't, which was due to improper
use (string comparison instead of numeric comparison) of dist conditionals
(by another packager, who requested that update to be added to our update
set, I'd have never made that mistake myself, though I am to blame for not
proofreading the changes). Due to bad timing, that build hit stable
directly (it got added to our Qt 4.5.0 update set just before we decided to
finally push it to stable after a long time in testing), causing a broken
dependency on F9 (which I fixed in the next push). But this was an isolated
occurrence which was due to a blatant packaging mistake (which could even
be caught by automated QA - any spec file containing "%{?fedora}" with the
quotes is broken) and which a maintainer experienced with multi-release
updates won't make. So I don't see pushing identical updates built from
identical specfiles for 2 or 3 releases at the same time as evil at all.

        Kevin Kofler

-- 
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