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
>manually?
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
>less grumpy.
And the hackers will have to bite into the QA report because if they don't,
then we get nowhere.
Andi
--
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]
