FW: [PHP-QA] release process

er, and i wasn't particularly clear, I would probably be prepared to volunteer for the testing procedure stuff - it would be good to have an opportunity to work with this. james > -----Original Message----- > From: James Cox [mailto:james@awpimajes.com] > Sent: Friday, March 01, 2002 10:26 AM > To: Derick Rethans; PHP Quality Assurance Team Mailing List > Subject: RE: [PHP-QA] release process > > > I'm very happy about this, it looks good, a very appropriate approach. > > about the testing.. i'd like to see tinderbox/bonsai set up properly so we > can run through standard build tests, and keep the build happy. > > Within the PHP family i'm sure we can find we have enough machines to run > tinderboxen processes. > > James > > > -----Original Message----- > > From: Derick Rethans [mailto:d.rethans@jdimedia.nl] > > Sent: Friday, March 01, 2002 10:17 AM > > To: PHP Quality Assurance Team Mailing List > > Subject: [PHP-QA] release process > > > > > > Hello folks, > > > > I promised to send a more detailed mail for the upcoming > release process. > > Please note that this is my view on it :) > > > > Timeline > > -------- > > 06-02-2002 Branch to PHP_4_2_0 > > > > Only the release master is allowed to merge fixes from HEAD > > into the release branch. This is to make sure no > stray changes > > in code end up into the branch, which are not > correctly tested > > during the RC process. > > > > After the branch point the QA should make a list of > what should > > be tested with more care than normally would have been done. > > I'll call them 'special' area's from now. Things like the > > fileuploading stuff should be mentioned here. Also some more > > tests should be developed/written here. The set of > things that > > follow from this pinpointing operation are the final > > requirements for this release. When they are solid here, they > > should not change during the RC process to make sure there is > > some point we can actually release, and not end up > with RC81 or > > something. Furthermore I think that one person (or two), the > > Test Master(s) should be responsible to write down > and maintain > > the the final list. > > > > > > 20-02-2002 Release Candidate 1 > > > > Ok, time to test the balls out of the RC. During the > RC1 period > > the Critical bugs should be tested, fixed and > exterminated. All > > bugs that are found during this RC1 and that belong to the > > critical category should be fixed before RC2. All > bugs that are > > found in the HEAD branch and get fixed should be merged into > > the release branch by the RM. This RC should be tested by QA > > and PHP-DEV. > > > > > > 03-03-2002 Release Candidate 2 > > > > After RC2 is release only severe and/or critical > bugs that are > > found in the HEAD branch should be merged by the Release > > Master. The main task of RC2 is to test all bugs > that are fixed > > during RC1 and of course more of the 'special areas'. Testing > > and the collection and ordening of results should be done by > > PHP-QA. > > > > > > 12-03-2002 Release Candidate 3 / Final RC > > > > In the most ideal situation all bugs that > > should-be-fixed-before-release are found and fixed now. This > > final RC should be tested by QA and match the > requirements set > > during the period between branch and RC1. > > > > > > 19-03-2002 Prepare release package > > > > If no critical bugs are found we can make the release package > > for the release. If any critical bugs are found, we > do a new RC > > every week. The reason to keep this short is that we actually > > want a release some day. > > > > > > 22-03-2002 Release of PHP 4.2.0 > > > > Work is done, time to release. > > > > > > Classification of bug severities > > -------------------------------- > > > > Normal bugs: Well, all little icky things that are not totally ok. > > > > Severe bugs: Bugs that deal with major malfunctions in extensions > > > > Critical bugs: Bugs that deal with malfuctions in mainstream (either > > minor or major). Mainstream modules are IMO: session, > > mysql, gd, odbc, mssql, curl, domxml, imap, > ldap, mcrypt, > > oci8, pcre, pdf, pgsql, standard :), xml and xslt > > > > Security related bugs in every extension > > > > Crash bugs in the mainstream extensions, or crash bugs > > that tend to happen a lot in non-mainstream > extensions (ie > > if enabling an extension crashes PHP). > > > > > > Release Master: I'd like to volunteer for that > > Release Bitch: Jani, he likes bitching ;) > > Test Master: Position vacant > > > > I hope this all made some sense, we've 5 days to reach consensus on this > > :) > > > > regards, > > > > Derick Rethans > > > > --------------------------------------------------------------------- > > PHP: Scripting the Web - www.php.net - derick@php.net > > SRM: Site Resource Manager - www.vl-srm.net > > --------------------------------------------------------------------- > > JDI Media Solutions - www.jdimedia.nl - d.rethans@jdimedia.nl > > Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands > > --------------------------------------------------------------------- > > > > > > > > > > > > -- > > PHP Quality Assurance Mailing List > > <http://www.php.net/> > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > -- > PHP Quality Assurance Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > >