Re: An introduction of the new cheerleader...

From: Chris Rouch (crouch_at_pobox.com)
Date: 01/29/04

  • Next message: Ron Herardian: "Re: Sendmail still will not read config files"
    To: fedora-list@redhat.com
    Date: Thu, 29 Jan 2004 12:03:56 +0100
    
    

    On Mon, 26 Jan 2004 14:21:27 +0100
    Michael Schwendt <ms-nospam-0306@arcor.de> wrote:

    > There is one particular thing I don't understand. Once an arbitrary
    > repository contains a new package, people don't hesitate to download
    > and install it. When it's broken or not as usable as expected, they
    > either downgrade or try the next repository (this experience is based
    > on comments seen in message boards), repeating this procedure
    > regularly. But when a package of the same software is in a public
    > queue of packages to be reviewed before they get published, people
    > avoid such packages like the plague and don't give the packages a try
    > and don't leave feedback.

    Maybe that's because of the perception that anything in a QA queue is
    'rawhide' quality, whereas anything released by a repository has
    undergone some (possibly rudimentary, possibly thorough) testing and is
    ready for the real world. It's been my experience since redhat 7 that
    rawhide mostly works but sometimes doesn't, and e.g. freshrpms almost
    always works.

    Having had such a good experience over time with freshrpms I'm inclined
    to keep using it, and other repositories which attempt (not always
    successfully) to stay compatible with it. From what I've read fedora.us
    and 3rd party repos are making no attempt to be compatible with each
    other. This is a shame.

    > I think
    > the community can do better than that. But the Fedora community has a
    > long road to take to realize that--like with the Debian GNU/Linux
    > project--it's better to spend a combined effort on a primary source of
    > reliable and maintained packages than to either want everything
    > maintained by Red Hat in "Fedora Core" or to keep an excessive list of
    > repositories maintained by individuals and live with interoperability
    > problems.

    It would be nice, but I'm not sure it's practical. For example Planet
    ccrma builds low latency kernels, atrpms build kernels with the v4l
    patches applied. I can't really see one repository maintaining these or
    other variants on the redhat kernels.

    What I'd like is for the independent repos to keep doing their
    packaging as now, but when a package is released by them it is submitted
    to Fedora QA to become a Fedora Extras package. Then people who have
    confidence in 3rd party repos could grab new packages early, and people
    who require a formally QA'd package could wait for the official Fedora
    release. But this will require a degree of co-operation that isn't in
    evidence at the moment.

    Please don't take this as a flame. I appreciate all the efforts that are
    being made - I just think things could be better.

    Regards,

    Chris
    -----------------------------------------------------------------
    Chris Rouch
    crouch@pobox.com

    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: Ron Herardian: "Re: Sendmail still will not read config files"

    Relevant Pages

    • Re: Fostering Cooperation (was Yum and EXTRAS)
      ... since repos like Dag intend compatability with Fedora base. ... After package improvement, ... repository, do not use the missing application you've elsewhere". ...
      (Fedora)
    • Re: Global variables
      ... I have a litte OT question: how do you initialize the Repository? ... first class triggered the Starter class. ... principle of object orientation is to design towards an interface, ... Starter class must not reside in the interface respository package. ...
      (comp.object)
    • Re: proFTPD?
      ... Setting up Install Process ... Parsing package install arguments ... FC-3 until you install fedoralegacy repository as FC-3 has now gone EOL ... The normal repositories for fedora core/extras no longer exists for FC-3 ...
      (Fedora)
    • Re: Fostering Cooperation (was Yum and EXTRAS)
      ... The page does not claim that cooperation would be ... The page is short and to the point in explaining why repository mixing ... that users of independent package providers should encourage them to join ... Fedora Core, it would be beneficial, if Fedora packages and their ...
      (Fedora)
    • Re: STS loading previous edition doesnt remove new classes
      ... classes which don't belong to a package will be made uncommitted. ... maybe you should ask people in this newsgroup if they ever encountered repository corruption. ... This wasn't what I was expecting - I expected that loading a previous ... Developer one can add 20 methods to class A, and developer two, 20 methods to class B and it requires manual merging? ...
      (comp.lang.smalltalk.dolphin)