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

Re: Delays in package processing



On Fri, 21 Dec 2007 15:59:58 +0100, Ralf Corsepius wrote:

> 
> On Fri, 2007-12-21 at 09:30 -0500, Jesse Keating wrote:
> > On Fri, 21 Dec 2007 15:17:18 +0100 Ralf Corsepius wrote:
> > 
> >   I'm perfectly fine and
> > encourage bugfixing across releases.  What I'm discouraging is version
> > upgrades for new features or spurious builds for spec fixes and other
> > unnecessary things that are done across the releases trees, not just on
> > rawhide.
>
> Of cause such things are happening, I don't deny them, but ... how can
> you be sure these updates won't fix something you're not aware about?

The more important question is: How do you find out they don't break
anything [else]?

You're baised, because you only see the _positive_ things in an update
procedure that has the potential to increase product quality. Most likely
that is because you intend to improve your packages (and the packages you
depend on) gradually, and if you do it painstakingly you can succeed.
Perhaps you pay close attention to changelogs and diffs when evaluating an
upgrade, maybe you perform related tests.
But can the same be said about all packagers? The Fedora community of
packagers consists of many different types of people. Some are upstream
themselves, some contribute upstream, some can fix bugs themselves, some
cannot fix bugs themselves, some are heavy users of the software they
package, some package more than they can use themselves regulary (and
obviously depend heavily on feedback from community-testers), some have
infinite trust in upstream release habits. This list is incomplete.

Theoretically, updates can be fine. Version 1.0 of pkg foo contains bugs,
version 1.0.1 fixes these bugs without breaking anything else. But we're
not there yet. Many upstream projects are not there yet either. And if we
modify our build requirements continously, we even increase the risk of
adding bugs. Version upgrades often include more changes than just
bug-fixes. Why take the step from the leading edge to the bleeding edge?


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