Bugzappers EOL process and abrt bug reporters being flagged with needinfo before bugs are closed?
"Jóhann B. Guðmundsson"
johannbg at gmail.com
Sun Dec 5 12:20:53 UTC 2010
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
More information about the test
mailing list