Re: RFC:PHP Release Cycle

From: Date: Thu, 09 Nov 2000 01:19:20 +0000
Subject: Re: RFC:PHP Release Cycle
References: 1  Groups: php.qa 
Request: Send a blank email to php-qa+get-1606@lists.php.net to get a copy of this message
Just from the traffic on the PHP-QA list, I would suggest that 24 hours is unreasonable for a testing time-frame. RCs go out and reports come in days later, once in a while even a week or two later. Obviously you can only stretch it so far, but I don't think 24 hours for volunteers using their spare time is a feasible turn-around. I also suspect that for some folks, PHP-QA is a weekend-warrior task -- So a Friday-Monday cycle would work but a Monday-Friday would not. I could be wrong, though. Maybe most QAers are doing it "at work" or in the evenings on "work" machines, and it's the exact opposite... Worst-case scenario, is there are some of each, and you need a full week for a complete QA cycle. This probably seems exceedingly long to OpenSource standards, but it really might be best for the current situation... In theory, an RC branch and its bug fixes should be "easy" to merge back into the main compared to a more general branching, or perhaps developers could even be encouraged to add RC bug-fixes to both branches, but new chunks of code only to the main branch... Kind of defeats the purpose of a "branch" in a general sense, but again it seems to fit the need here. If that's not feasible, having developers not commit anything except RC bug-fixes seems the only other option. But the PHP QA team simply can't be effective if large-scale code-changes occur between sub-RC releases. Disclaimer: Easy for me to spout off -- I'm not the one doing the work here. You guys rock!

« previous php.qa (#1606) next »