RE: [PHP-QA] RFC:PHP Release Cycle

From: Date: Wed, 08 Nov 2000 23:35:36 +0000
Subject: RE: [PHP-QA] RFC:PHP Release Cycle
References: 1  Groups: php.dev php.qa 
Request: Send a blank email to php-dev+get-37470@lists.php.net to get a copy of this message
I don't disagree that there needs to be some method put into place to control the code that is being tested for the RCs. However, I seem to remember that one or more of the developers (Zeev ?) really hate branching (AFAIR due to problems with merging the branch back into the main tree.) Personally, I am afraid to get into this discussion - it is outside the scope of my experience. However, not knowing what I am doing has rarely stopped me in the past, so here are my thoughts on this topic. I think that QA and preparations for a release should be an ongoing, semi-automated process. The QA team members set up a cron event to update cvs. Each morning, build the source, run the tests and report any bugs or problems. Bugs will be marked for fix on an upcoming release. When it is time for a new RC, the codebase gets frozen for a day. Problems get reported, changes get made and either a new RC gets rolled or the release gets rolled. Having a group of people building and testing each day should really cut down the accumulation of bugs, making the whole RC process a lot faster and easier. --zak At 11:15 PM 11/8/00 +0000, James Moore wrote:
Hi James, Unfortunately, I could not do a thorough review of your RFC. However, given that there have been no replies to it yet, I felt that I had to give you some feedback. :) I have taken the RFC and structured it as it made most sense to me. I have also taken out the information on how the codebase is managed for the RC process. The developers have had this discussion several times already - they will have to arrive at their own solution (hopefully without bloodshed :) I was trying to get some discussion on this and the reason I suggested this codebase change was to make us more reliable.. at the moment and RC is rolloed and then we review it. If showstoppers are found then they are fixed and a new rc is rolled. This is then posted back to us. Now this process would be fine if the PHP Codebase was fairly static but what we are finding is that some fairly new untested code makes it into the Repository between RC's now I dont have time to spend testing 2 or 3 different RC's in fairly quick succession so the first one gets tested well, the second less well and by the third I have other things to do. Now I think part of the problem with the realease of 4.0.3 was that the RC's were too far apart and too much code was added inbetween the releases. I think that for us as a QA team to do a decent job of tracking bugs in releases we must insit that this or somthing comparable happens during the release cycle otherwise we have a far more difficult job than the developers do having to alter 2 files or copy one between 2 checkouts to commit to both trees. Perhaps this simplified format will make it more likely that people will comment. HTH, Zak THanks Zak.. begining to get worried my mail servers were not working... James -- 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


« previous php.dev (#37470) next »