Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:23383 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34290 invoked by uid 1010); 15 May 2006 17:10:14 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 34274 invoked from network); 15 May 2006 17:10:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 May 2006 17:10:14 -0000 X-PHP-List-Original-Sender: sesser@php.net X-Host-Fingerprint: 81.169.145.170 natlemon.rzone.de Solaris 10 (beta) Received: from ([81.169.145.170:37322] helo=natlemon.rzone.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id DA/34-19568-4F5B8644 for ; Mon, 15 May 2006 13:10:13 -0400 Received: from [192.168.1.77] (p50874525.dip.t-dialin.net [80.135.69.37]) by post.webmailer.de (8.13.6/8.13.6) with ESMTP id k4FHA5b2009509; Mon, 15 May 2006 19:10:05 +0200 (MEST) Message-ID: <4468B5EB.7000602@php.net> Date: Mon, 15 May 2006 19:10:03 +0200 User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Andi Gutmans CC: PHP internals References: <4468848D.5020602@php.net> <7.0.1.0.2.20060515091102.044df950@zend.com> <4468AD19.5020306@php.net> <7.0.1.0.2.20060515094147.02b55a70@zend.com> In-Reply-To: <7.0.1.0.2.20060515094147.02b55a70@zend.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP Release Process Sucks From: sesser@php.net (Stefan Esser) Hey Andi > My point was that this has nothing to do with Zend or not Zend. My point is not that someone from Zend broke it, but that someone from Zend blamed the community that THEY failed to find the problem. I thought Zend is enough into PHP to test their own products against RC's, too. It makes me angry that in the last months again and again people who earn their money with PHP come and insult those who work on PHP for free and do all the hard work. > It's happened to all of us in the past (except for maybe you) where we > have commited code that had problems. Hehe... I also commited code that cause problems in a release... Like a very slow unserialize() in 4.3.??. And yes I tested it back then but unfortunately that bug only was causing problems were large quantities of data had to be unserialized. > So people screw up. I prefer having the occasional screw up then less > people helping out. Yeah. But maybe we should setup some rules what exactly we should do when there is a broken tarball or missing files. While it seems nice to just repackage and silently change it (or change it with a warning), it is considered bad practice and is especially bad for people using distributions like Gentoo or the BSD ports system. Even if we don't change the version number we could rename the tarball to php-5.1.4-repack-1.tar.bz2 or something alike.