Re: RFC:PHP Release Cycle
| From: | Richard Lynch | 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!