Delays in package processing

[Ralf Corsepius]

On Fri, 2007-12-21 at 17:10 +0100, Michael Schwendt wrote:
> 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]?
I consider this aspect as non-important, because packages which don't
work or break will hit back at the packagers and their upstreams in the
in quite short terms, unless there are political, marketing or other
reasons which overrule.

Unfortunately the latter typically are those who prove to be those to be
the really harmful ones.

> You're baised, because you only see the _positive_ things in an update
> procedure that has the potential to increase product quality.
I don't think I am biased. I'd call it experience originating from long
term involvement in OSS. 

In a nutshell, it's quite simple: OSS is an evolutionary process. Bugs,
personal mistakes and faulty decisions are a natural part of this
process.

>  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?
Frankly speaking, I am expecting packagers to do this and regard this as
their minimum duty. If they don't, they shouldn't be packagers and won't
be packagers for long.

>  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.
No disagreement ... all packagers at some points in their career have
been in one or more of the positions you descripe and made experiences
on their own.

Suppression, supervision and prohibition won't help, people need to go
through learning curves themselves (Prohibition <-> moonshine ;) )

> 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.
Then they should not be part of a stable distro, or at least no be part
of the "mandatory parts".

>  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?
Because Fedora already is the unstable bleeding edge?

It's not because community packager added unstable stuff or did an
unreasonable job, it's primarily because political and marketing forces
outrule "reason".

Ralf