In an effort to stop a long going ping-pong again, let's concentrate on
figuring out what was wrong with the old release, and trying to improve it
in the future.
I'll start by saying that generally, overall, the last release was pretty
good. Ok, so COM didn't work, but only a very small number of people is
actually affected by this. Overall, the QA process *worked*.
To get to fix the bugs in the QA process, we need to look at the exceptions
to the rule, i.e., the things that didn't work out right. The first and
obvious example then, would be the COM module.
I believe that the main difference in the COM module patches, when compared
to other patches, is that it was mainly to implement new functionality, or
to rewrite code in a better way. We should probably have a guideline that
new code/code rewrite patches should not be submitted to RC branches.
Another issue was the inability of people to deliver patches on
time. I.e., there were quite a few patches that were important to put in
the release (i.e., fixed bugs) but came in after 'the last RC' was
announced. That's one of the reasons we had so many 'last RCs' in this RC
round. Whether there's a good solution here is not very clear; My guess
is that there isn't. The question is whether we should be more aggressive
about dates (i.e., if you didn't submit your patch on time, it's your
problem) or not. There's no good answer here IMHO, comments welcome...
Those were the two main broken things about the last release. Let's
concentrate on fixing them instead of rethinking the whole architecture,
because it *worked*.
Zeev
--
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]
