unfrozen repo somewhere?

[Horst H. von Brand]

Ralf Corsepius <rc040203 at freenet.de> wrote:
> On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote:
> > Ralf Corsepius <rc040203 at freenet.de> wrote:
> > > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
> > > > "Horst H. von Brand" <vonbrand at inf.utfsm.cl> writes:
> > > > > Ralf Corsepius <rc040203 at freenet.de> 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