Bugzappers EOL process and abrt bug reporters being flagged with needinfo before bugs are closed?

["Jóhann B. Guðmundsson"]

On 12/05/2010 11:11 AM, Alexander Kurtakov wrote:
> On 01:04:02 pm Sunday, December 05, 2010 Jóhann B. Guðmundsson wrote:
>> On 12/05/2010 12:06 AM, Brendan Jones wrote:
>>> Is it really so bad?
>> Yes and reporters should be able to opt out from this process chooses
>> they do so.
> Well, how about giving maintainers the power to opt out from having bugreports
> about their packages?

You do realize that I'm speaking about the bug zapper process here and 
as far as I know maintainers can choose to opt out from that process 
chooses they do do so and so should reporters.

> Come on, we can't be serious discussing this yet again.
> My POV is that the reporter is obliged to do that in the same way the
> maintainer is obliged to take care of his bugreports.  Yes I know that there
> are bugs that haven't been looked at all but there are also bugs that contain
> no useful information.

Certainly that is true and at the time when we had around what 6000 - 
7000 the time I started writing how to debug components pages to address 
that lack of useful information from reporters and I suggested that we 
made it mandatory for maintainers/packagers to provide that information 
including test cases for any new packages that would be brought into the 
project ( so we could play catchup to the already existing ones ) 
because it was apparent then that we could not keep up with writing how 
to debug pages for vs components being brought into the project.

It got scrapped off the table because it was considered to much of a 
burden for maintainers/packages. WTF!

Let's just say now roughly what 10000 packages later things have not 
improved and QA is still trying to come up with various solutions 
workarounds to address this problem through various update policy and 
processes like "proven testers" ( which is doomed to failure due to the 
above ) which in the end will be extra work on those maintainers that 
actually are doing a good job of what they do ( thus should not be 
receiving this extra burden ) simply because people refuse to accept and 
face the fact if they want to increase the overall quality of the 
distribution they need implement stricter process on accepting packages 
( and the people behind it ) and educate packagers/maintainers about the 
responsibility and the duty that comes with it and those that can not 
follow that process their components will be put up for grabs for a 
maintainer/packager that can or dropped out of the distribution.

I will applaud the day FESCO actually gets their head out of their 
assess ( pardon my french ) and does something about this and implements 
a seriously strict rules regarding packages/maintainers and their 
components in the project those that scream if and when FESCO implements 
it are the once that should not be maintaining packages in the project 
et all.

> Let's face the truth - buts gets fixed when both the maintainer and the
> reporter care about it. And if neither the maintainer nor the reporter care to
> take a look, reproduce and move the bug to newer version there is no point in
> keeping it open - it will never get fixed because both supposed to be
> interested parties don't care.

You can certainly reduce that problem by half by removing the components 
out of the process which do not have are responding maintainer behind them.

JBG