Re: We Want Quality

From:	waldschrott	Date:	Thu, 29 Jun 2000 18:11:13 +0000
Subject:	Re: We Want Quality
References:	1	Groups:	php.dev
Request:	Send a blank email to php-dev+get-22852@lists.php.net to get a copy of this message

in my opinion there should be a weekly (or at least immediately after announcing a RC) *Basic Distributed Quality Assurance System* BDQAS :) testing a few of the *major modules* (mysql...) on a few of the *most important OSs*, I think that´s Linux AND Win32 every week or so, would be a sufficient quality assurance, using a standard test scheme should cover most the most obvious bugs, I think these are... - PHP 4.0.x won´t compile on a major OS - PHP 4.0.x won´t compile with a mafor module - PHP 4.0.x crashes on a major OS - PHP 4.0.x crashes using a major module we should assign a *simple task* to the *most frequently available users and developers* for several modules or OSs: I would take the build *Win32* and do *basic tests part* eg. mysql and odbc - whenever a RC is planned, these people have to stop all work and do these basic tests, if not or they do not cover a basic error - they´re lynched :) - an actual *code freeze* is not necessary if the last RC (the one which will be the next release version) gets code freezed and all of the mentionned people do their basic tests on it, when all of them returned positive results and even it´s only after 3 hours it should be released then, if a person did not receive within 24 hours someone should take his part just an idea Zeev Suraski wrote:

On Thu, 29 Jun 2000, Sascha Schumann wrote:
    The recent trouble has shown that our release process is far
    from being perfect. In order to achieve better quality
    releases, I urge the PHP community to adopt a couple of
    simple rules:
        Do not release anything untested.
Nice concept, except we do not have the resources to do that. We tried to do that by letting people test the code 3 days in advance, which did not discover the Windows CGI problem.
    This will delay releases until all obvious bugs are found.
    That is good. This will also catch bugs which were introduced
    through other bug fixes. That leads to the second postulate:
        Do not add features during release time.
No features were added during release time, AFAIK. If you refer to the DISCARD_PATH issue that was the source of the Windows CGI bug, it was a bug fix, not a new feature.
    The simplest feature can break something. Changes are bad.
    Avoid them. 
        Do not act hasty.
    Release candidates can get thrown out hourly, if necessary.
    The final release candidate should be available to the public
    for at least five days. 
This is completely unfeasible, and can definitely not live peacefully with your previous suggestion. We can't halt development for 5 days, it'd simply not work. Even holding the code in a semi-frozen state for 3 days between the RC announcement and the Release announcement is almost mission-impossible; Keeping a 100% frozen codebase for 5 days between the last working RC and the Release is both not doable, and not something I would like to get to anyway. We should still behave like an OpenSource project and not like a bureaucratic company. Zeev