Re: We Want Quality

On Thu, 29 Jun 2000, Sascha Schumann wrote: > On Thu, 29 Jun 2000, 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. > > Please keep an open mind. These are general guidelines. I am; Your strict instructions were the ones who seemed not to leave any room for an open mind (they pretty sound like army-style orders, to be honest :). As a general guideline, testing before releasing is always a good idea, and we employ this strategy, better or worse, since the dawn of PHP 4.0, and even earlier. Nonetheless, we have to face the fact that we don't have a QA team, and that we rely completely on user feedback, and on developers' response to this feedback. The DISCARD_PATH issue may be a great example of how we, as developers, can fuck up; Unfortunately there's no bulletproof way to prevent that from happening in the future, except for trying harder. > > 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. > > Other projects can do it, so I don't see any reason why we > cannot. You might want to elaborate on this point. I don't have anything to elaborate on; Considering the number of PHP code contributors and the huge amount of different (and unrelated) pieces of code, it's simply not feasible to ask everybody to stop their development for a period of 1-2 weeks (allowing several days for RC's, and then freezing 5 days before the last RC and the release). > > 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. > > We have a bad history of last-minute updates *after* the > release (i.e. PHP 4.0.0 and 4.0.1). I don't want to continue > with such a crappy release procedure. If you have a proposal > which addresses this problem, please tell us. Most projects I know have done this at one point or another, both commercial and opensource (especially opensource). We did not invent the notion of patch levels. I agree that generally, any different release should be labeled with a different version and package name; I don't consider a 4.0.1pl1 released shortly after 4.0.1 a catastrophy. As far as I recall, there was only one other case in which something similar happened (I think it was even worse, something that caused gpc being turned off to crash PHP), which was my fault. We released a pl shortly afterwards, which solved the problem. I don't think that it ended up being catastrophic either. Nonetheless, making changes in central places a couple of hours before the release is indeed not a Good Thing, and we should indeed try to avoid it as much as possible. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/