> Have you checked the bug database lately?
> There are 43 open reports with bug type 'Reproducible crash'.
> There are actually even more of them. I can easily reproduce
> at least 10 bugs which cause segfaults. Those haven't been fixed yet.
> Those haven't been fixed for a couple of releases now.
> So, with your logic, we shouldn't release before all of them are fixed?
[snip]
I agree, no version will ever ever be 100% perfect. There will always be some
quirk, or some feature which isnt always right. As you said, QA is to test it
and make sure we've nailed down ALL the problems before it goes out, and those
that can be fixed are. Those that cant in a reasonable amount of time, or
arent deemed a necessary fix or common problem get left till next time.
However, as you say, there are quite a few problems which STILL dont work. I
appear to have closed 1 bug which was a seg fault, as I tested it with the CVS
release of the time, but now again, it appears to have broken. So, I need to
go back and reopen it. I can recreate it on 2 versions of linux, so, it
suggests its something bad. And just to check, no it still seg faults.. it
always has, except for 1 version of the CVS which meant it got closed.
What I think we need to do is chat with the developers and come up an
agreement
Maybe something like this
1. Any problems which result in seg faults/gpfs are show stoppers, code doesnt
go out till its fixed, or feature is removed till we can fix it.
2. When we hit say RC1 all the features we want to see in the new version are
in, no one ones are added, only bugs fixed.
3. If a developer is unhappy/unable/unwilling/not able to solve problems
within their module for whatever reason, a second person who is able needs to
be sought.
The QA team maybe need to vote on a bug and say if they could recreate it, if
no one can recreate it a bug is perhaps less serious than one everyone can
recreate and it gets a weighting flag accordingly..
Another idea would be to list supposedly fixed bugs in the release, and any
new features..
Am I mad? this is how our QA team worked.. It does take give and take on both
sides as if QA were right, no product would ever leave, but if most developers
had their way (I speak as one as well) we'd rather play with new bits or not
worry if we dont see it it cant be so important..
We arent children, we should be able to sort it out.
--
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]
