Re: 4.0.5: Merge Request

> 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