[Zeev Suraski <[EMAIL PROTECTED]>]
> 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*.
We need to fix either the scope (bugs that need to be fixed) or the
release date, and stick to that. Tradition is to move the release
date. If we move both at once, we're in trouble and chances are it
will delay the release even more.
So, if the showstoppers are identified before rolling the first RC, we
can either fix them first, or roll the first RC and fix them all
before rolling the second (depending on the general activity on the
main trunk, IMHO it would be better to do two RCs).
We'll always have the problem of "I need to MFH this, pretty please",
but I think that started working well at the end of the 4.0.5 QA. :-)
- Stig
--
Stig Sæther Bakken <[EMAIL PROTECTED]>
Fast Search & Transfer ASA, Trondheim, Norway
--
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]
