At 11:04 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > 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
For the QA guys it might be nice to be able to flag certain bugs in the bug
database and then automatically create a summary page which could be sent
to php-dev. However, I think it would take too much time to get started.
Maybe just manually creating a list with a one line description of bug #,
where the bug is and a short short summary would be best. This could be
sent to php-dev.
>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
And the hackers will have to bite into the QA report because if they don't,
then we get nowhere.
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]