Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner <antarus@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

Mike Frysinger wrote:
> On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
> 
>>28.2.2006, 21:39:43, Mike Frysinger wrote:
>>
>>>whats your point ?  if an ebuild author wants to control the SLOT, then
>>>they should be able to without having an invalid warning issued on the
>>>subject
>>>
>>>considering the nature of the warning, it should be trivial to make it
>>>into a proper QA check by having the class see where files were installed
>>>and then warn/abort if certain conditions are met
>>>
>>>there's no reason for the user to see this crap
>>
>>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
>>eclass inherited illegally crap and a couple of others - this isn't going
>>anywhere.
> 
> 
> unrelated ... that is a portage limitation that has deeper work going on 
> around it to resolve the issue properly ... this is an eclass limitation that 
> can be resolved now
> 
> 
>>You are trying to solve something that noone ever complained about. Why not
>>rather solve stuff like ebuilds that depend unconditionally on arts, but
>>because they inherit kde eclass they get bogus arts use flag from the
>>eclass. This is an issue that's truly confusing and that people are filing
>>bugs about. There's the difference between doing something useful and
>>wasting time on an artificially invented issue.
> 
> 
> right, so from now on people shouldnt bother fixing issues until a bug is 
> filed, that way we know someone actually cares enough to have the issue 
> resolved
> 
> today's lesson: proactive QA is frowned upon, it's only a bug when a user 
> files a report at bugs.gentoo.org
> -mike

Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see
bugs filed in almost all circumstances.  If QA and the maintainer can
fix stuff without bugs, thats cool, especially for trivial matters.  If
QA and the developer aren't getting along on a specific issue then there
is no reason NOT to have a bug open.

Otherwise you get circumstances that were also discussed, such as "I
told the maintainer in person over a year ago..." which may in fact be
true, but people forget things and make mistakes and now you have
nothing to point at for proof of inactivity except a vague statement.
Better to cover your rear and be able to point to a year old bug with a
solution attached, and be like "look there is a bug and a fix and no one
did jack squat."  Essentially you have a case for any sane developer to
agree with.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]