> Having a better defined/reproduced list of bugs is a must and if the QA
> team can do that PHP will definitely benefit from it. However, today when
> they ask people to fix bugs they are often not fixed and I don't even think
> that they are necessarily looked at. That is why a defined "everyone join
> forces to kill the bugs" period would be a good thing. And whoever doesn't
> help isn't allowed to hack on his extension anymore (Just kidding :).
Yes, but that is my point. They should not be asking people to fix bugs.
They should simply be identifying and prioritizing the bugs. As a group
we need to fix the bugs. Jani is complaining that they are ignored, so we
need to change the atmosphere and remove that aspect from their duties.
We are not going to change the way developers do their day-to-day jobs by
much. But by changing the approach to one that is centered around an
itemized list of issues I think we will completely change how things work.
Imagine if there is only 1 criticl bug left on the list and it is in a
piece of code you wrote? Everyone sees this list and everyone can see
that as soon as this bug is fixed the release can go out. That will
motivate a developer into holding off on playing with cool new features
and taking a look at the bug.
The question right now is how to best implement this. Do we add something
to the bug database to flag bugs in some manner and have a release
candidate summary page?
Or do we separate it out of the bug database and maintain the list
manually?
I think this is something for the QA guys to bite into and answer if they
agree that this sort of approach would improve their lives and make them
less grumpy.
-Rasmus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
