Summary - Broken dependencies in Fedora Extras - 2006-11-24

[Michael Schwendt]

On Sun, 26 Nov 2006 08:42:00 +0100, Gianluca Sforna wrote:

> > On Sat, 2006-11-25 at 17:42 +0100, Thorsten Leemhuis wrote:
> > > Michael Schwendt schrieb:
> > > > On Sat, 25 Nov 2006 07:48:31 -0800, Christopher Stone wrote:
> > > >[...]
> > > >> There needs to be a way to
> > > >> blacklist these packages from showing up in the report or else send
> > > >> them to another interested party such as fedora-legacy
> > > > I've suggested a black-list several times before without clear
> > > > feedback. Black-listing packages is like hiding something under the
> > > > carpet.
> > >
> > > Agreed, until now I don't see any good reason for a blacklist.
> >
> > How about FESCO implementing some rules on "taking consequences" from
> > EVR issues in FE not being taken care about?
> >
> > E.g. "broken deps > 4weeks", and the package will be automatically
> > orphaned plus the maintainer's account will be withdrawn/canceled?
> >
> 
> This sounds a little overkill (despite I agree 4 weeks are plenty of
> time to fix broken deps).

We should stop considering anything like real QA if we are one step closer
already to creating an non-healthy community environment where everything
is based on "either shut up or fix the crap yourself" or where apparently
things slip through because "nobody cares".

Keep in mind that, preferably, every growth of the packager community
should _reduce_ the load on individuals and increase the availability of
human resources, which in turn increase the possibilities for team-work or
even redundancy. The opposite is when growth of the community increases
the load on some individuals (Security Team, QA Sig, other packagers who
suddenly are confronted with a broken dep-chain).

Since you cannot force volunteers to become co-maintainers of an arbitrary
package, other actions are needed. To make sure that long-time broken
packages don't pop up like mushrooms. Perhaps because some contributors
try to take care of too many packages. And to make sure that trying to
clean up the dist of fire'n'forget packages and AWOL maintainers shortly
before the next release doesn't require increased efforts.

> Wouldn't be enough to remove the offending package from the repo?

WRT plague it didn't take long until somebody reported the missing
packages as a bug. ;)

In general, it is more interesting to learn why packages in "stable
releases" of the dist remain broken for such a long time and whether some
packagers are overloaded and should not add further packages.

As an example:

    jeff AT ocjtech.us
        linphone - 1.2.0-4.fc5.i386    (46 days)
        linphone - 1.2.0-4.fc5.ppc    (46 days)
        linphone - 1.2.0-4.fc5.x86_64    (46 days)

ABI breakage in a library upgrade that was pushed to Extras. There is a
chain of bug reports about it, including complaints of users.