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

Re: Delays in package processing



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


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