On 10/06/2016 03:27 PM, Adam Williamson wrote:
On Thu, 2016-10-06 at 10:39 +0200, Hans de Goede wrote:
So I like the idea, I do propose to simply re-use most of
the blocker bug process for this, rather then inventing yet
another process. I guess this could even be integrated and
the way to get bugs on the list would be to propose them
as blockers as normal and then during the blocker meeting
when the vote says "no this is not a blocker" a second vote
is done to see if it is a critical bug.
Let me phrase my earlier objection a little more strongly and
personally:
If someone tries to make me spend another three damn hours a week
reviewing 'proposed critical bugs' I'm going to jump out a window and
go start that yak farm. You won't see me for dust.
Interesting to see that now the person responsible for adding additional
load on the QA community want's to jump out of windows after doing so.
You reap what you sow...
As I mentioned sometime back in my QA days, QA should just take care of
the installer/core/baseOS, then each sub community that delivers an
product of some sort into the hands of an end users needs to take care
of QA-ing it itself for whatever it builds on top of that and arguably
the rest of the release process for that product.
Then the release process needs to be scaled from supporting just a
single product ( which has never reflected what the community has ever
done since there have always been more then one product in circulation
from the community ) designed in such manner that product A cant block
product B or C or F.
I have never understood this whole attitude of always putting all the
load on QA and Releng which has never had any resources to effectively
manage it for everybody to begin with.
JBG
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
