Re: Release process

How silly would it be to have: RC1p1 RC1p2 . . . and RC2 for everybody to test, with more like a week projected between full RC's instead of a day or two. IE, you *know* there is going to be some critical patch that won't get turned in for a week, so don't even call it RC2 and do a full QA on it? Disclaimer: I'm not even sure *I* think this is a good idea... -- WARNING richard@zend.com address is not working -- Use ceo@l-i-e.com Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm ----- Original Message ----- From: Zeev Suraski <zeev@zend.com> To: <php-qa@lists.php.net>; <php-dev@lists.php.net> Sent: Thursday, May 03, 2001 4:40 AM Subject: [PHP-QA] Release process > 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 Quality Assurance Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net > For additional commands, e-mail: php-qa-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net