Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote: > > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote: > > > > "Horst H. von Brand" <vonbrand@xxxxxxxxxxxx> writes: > > > > > Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > > > > > To imagine that it's workable for the majority of > > > > projects is to demonstrate lack of connection to reality. > > > Pardon, but you probably can relate, why I have to disagree on this. > > > I would turn this argument around: The apparent lack of quality of the > > > distro, the amount of bureaucracy and ineffectiveness the Fedora > > > approach cause are a living proof for a non-functional approach. > > How do you measure "distro quality", > My subjective measure is "distro works for me without major effort". Done long ago. Sure, some rough edges do remain always, but it isn't "major effort" for Fedora (hasn't really been for all of Red Hat then Fedora history as long back as I remember). > Reality is: This doesn't apply. > > "amount of bureacracy" (and how much > > of that is "too much"), "effectiveness"? > koji, bodhi, packagedb, acls, freezes, bugzilla, trac, wikis, All tools meant to /decrease/ workload (or make it more productive). > mails to > rel-eng/<committee dejour>, Sad fact of life is that once the crowd grows too large, some explicit coordination has to come in. > the "incident", Not Rel-Eng's fault, I'd sincerely hope. Sure, it would have been better to have procedures in place to handle such in a more streamlined way, but then again that would either mean the incidents are so frequent that everybody knows in their sleep how to handle them, or having a think-tank planing out all possible (and imposible) scenarios and lines of action, resulting in a lot of extra bureacracy and friction. > the triagers, What is the problem with them? They are supposed to validate that bugs are for real, so I can't see how they hinder development progress. To the contrary, they should prevent developer's inboxes clogged with useless bug reports. > server > downtimes, Always bad, true. How do you propose help here? > mirror latencies, Not Fedora's fault; more the contrary, as Fedora is popular more mirrors are needed (and problems with any one get more visible). > bugs not getting fixed, ... Developer's fault. How do you want to fix this? Training camp for newbie developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs in Fedora 10" listing patch contributors, bug triagers, ...)? User's fault (Yes, I've been known to vanish from sight and not following up on my own bug reports when I was too busy elsewhere). > All together (not worth mentioning all the bugs and nits they suffer > from) have a massive impact on effectiveness. Openly said, it has hardly > ever been less effective to contribute to Fedora as it is in recent > past. Please, /show/ how to make it better. /Tell/ where or how the workflow could be streamlined. "More branches" just makes for a swampy river delta, not smoother flow AFAIKS. > > I'd say the fact that we are discussing this shows that the qualility is at > > least decent enough for serious consideration. > Certainly - Otherwise, I wasn't be using Fedora. It's certainly not perfect, but good enough for me (and fun to booth!). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
