Michael Schwendt <mschwendt.tmp0701.nospam <at> arcor.de> writes:
> It is circumvented too easily. Packagers raise the karma for their own
> packages. Release people don't reject quick pushes from testing to stable,
> which are not security related or critical.
Why should they? Release engineering plays an important role in Fedora, but
they are a small team compared to the huge number of package maintainers, they
cannot really be expected to know more about the package than its maintainer.
The maintainer should be the one who knows best what to push.
There are already complaints that Fedora is too bureaucratic, having to
justify "criticalness" of each upgrade makes it worse, not better.
> The problem is that too many updates don't fix real-world problems or
> issues reported in bugzilla tickets.
>
> They are ordinary minor version updates with no or questionable benefit
Many of those minor version updates do fix real-world bugs. In general, that's
the entire point of releasing an update upstream. Even if they aren't listed in
bugzilla.redhat.com, that doesn't mean they didn't affect Fedora.
> (such as uninteresting changes, huge autotools updates,
Now if the ONLY changes are just autotools updates or other cleanups with no
actual effect (like "change variable names to be more readable"), I agree that
it doesn't make much sense to push the update. But maintainers normally don't
push these. ;-)
And then there are cases where an autotools update can actually fix problems,
e.g. rpath-related issues, libtool dependency bloat, ... Maybe even issues
which are more serious for the end-user than these, though I don't have a good
example on hand.
> dangerous from-scratch-rewrites,
Sometimes partial rewrites are the only way to fix bugs (in a reasonable
timeframe). For example, the KDE 3.5.7 KMail IMAP filtering regression was
fixed by switching to the kdepim enterprise branch where the IMAP code had seen
significant changes.
> stuff that invalidates the results of the fedora development testing period,
That's a pretty vague statement. I don't think any of the updates being pushed
really do that.
> spec "fixes" for packages that built fine,
That's also too vague. Sure, pushing an update only for a fixed License tag is
lame, but not many packagers did that. Some specfile issues are noticeable by
the end user, e.g. unowned directories which can stray around on the file
system, wrong permissions etc. And in many cases, the specfile cleanups were
simply part of an upgrade to fix an actual issue which was synced from the
development branch. Using the same specfile everywhere reduces the amount of
maintenance needed and also reduces the risk of a screwup which was missed
during Rawhide testing.
> superfluous %config modifications which trigger .rpm{new,save} and annoy
> users who actually use the software).
Configuration changes are also usually done for a reason.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
