begin quote On Tue, 15 Jul 2003 12:39:54 +0100 "Stuart Herbert" wrote: okay, I'll start this off in a way that probably suits another forum better, but I can't stop myself after theese posts about QA.. Yes, its a flame. > > I hope you realise that your desires are conflicting. more > > ebuilds leads to > > more unmaintained ebuilds. More QA needs more time. > > Rubbish. Totally utter rubbish. > > The right levels of QA *save* time, because things are done > as-right-as-they-can-be first time. Instead of time going into bug > fixing and constantly re-doing what has been done, the time instead > goes into moving forward, and doing new things. *Too much* QA just > bogs the whole thing down, and makes it impossible to get anything > done in a timely fashion. The two are very different. [SNIP] > What are *your* proposals for addressing this? I'd like to hear them. POLITICIAN!!!!! Mommy Mommy he's a politishian!! he bashes views without having information!! POLITICIAN POLITICIAN!!! *WEEEEE* Take the scary man away. Lock him in a jar and make him read the herds proposals and implementation which he has obviously heard about (Why else would he suggest something thats documented as in-progress and then balk out "What have you come up with? come come show us your ideas! " ) *Sigh* And now for a more structured answer. No, a well-done QA will -not- let a single developer manage more than say ~30 builds, and perhaps even less if they are complex. At this point one can do two things. Either kill all packages that are unmaintained by a herd.... (And hear the whine from the same crowd that demands proper QA) ... or give developers to them. Now, assume that each dev can handle approx ~30 packages, for our approx 5000 packages we need around 170 devs. We dont have that, which makes a few of our devs overstrained, as well as some packages unmaintained. Now add to this that some devs do other work than maintain packages (oh, gasp ) and you can decimate a few more from our ranks. So, we can throw more devs into the pool, without doing proper QA on the devs (which has been in place for quite a while, mentoring programs and so on) or handle them as the bugs crop up. All through this we hear from our QA demanding users.. "MORE PACKAGES MORE PACKAGES! WE WANT MORE! WE WANT MORE!" At this point last we introduced a buffert-zone (testing packages) and even stricter rules on packages. No betas, no alphas, no live-cvs. ("but we want this package, its really cool and actually builds..... no, I haven't tried it..." we hear from some disgruntled bugzilla users) To throw more devs at the group is something I feel as a foolish thing if introduced in too rapid succession, sure, some QA might be handled that way, but we cannot assure the developers QA. Tinderboxing and automization was in progress but was shot down due to hardware and maintainability reasons. Oops. out of date, we have bugzilla. people use it. of course, some people use it as if its freshmeat. (dont bother, we subscribe to freshmeat, -announce lists and others, most of the time packages in active tagging are updated soon enough. if you find it stale for a week or so, then poke bugzilla) Encourage more uipstream manager s to maintain ebuilds.. .*ew* *shudder* I already get to take bugreports semi-daily from people who in their $INFINTIE_WISDOM start using builds from BREAKmyGentoo or other places in mixture with ~x86, whereby we have to track down a three level subdependency issue to find the linking error which stemmed from the interfacechanges in the development series... (this alone could be enough to warrant a ramble, I'll avoid that. most of our users deserve their root account. ) Remember, I am not part of management, or representing the whole devteam here. I'm just me. //Spider - irate developer -- begin .signature This is a .signature virus! Please copy me into your .signature! See Microsoft KB Article Q265230 for more information. end