Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50505
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=kSnTo++ojvlIiUiiBoHMhwM1rFY3QP/W/fkt2dYGiv13U0rUNKEidXWnj8+wVCfTpz
         BxcQtBz5jm1cAs7LaUq9qd8rK8Cyp3RjWXVteZdHM5u/tqQ9KYV94P2wi8szSe55TiQU
         ry1u5qpf1cTyw90+9p6aIA9sSIXM0utaauCFY=
MIME-Version: 1.0
In-Reply-To: <8757232E56758B42B2EE4F9D2CA019C9142FA2@US-EX2.zend.net>
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com>
	<alpine.DEB.2.00.1011231002140.24401@kossu.derickrethans.nl>
	<4CEDF661.3090800@sugarcrm.com>
	<8757232E56758B42B2EE4F9D2CA019C9142FA2@US-EX2.zend.net>
Date: Thu, 25 Nov 2010 09:48:20 +0100
Message-ID: <AANLkTi=__1ZrK4dKVEH0ZN-W4r2LcG7K5xommFb+mM37@mail.gmail.com>
To: Andi Gutmans <andi@zend.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Derick Rethans <derick@php.net>, 
	Felipe Pena <felipensp@gmail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Release Process
From: pierre.php@gmail.com (Pierre Joye)

hi Andi,

On Thu, Nov 25, 2010 at 7:42 AM, Andi Gutmans <andi@zend.com> wrote:

> I agree with that. More structure and predictability will be very valuabl=
e to the project. We created a lot of structure in Zend Framework and it ha=
s really paid off.
> Btw, we don't have to look far. Just the change in having people document=
 their suggestions via RFCs already had a substantial impact on this projec=
t both in terms of peer review and having a long lasting trail of what made=
 it into a given release.
> More structure will typically yield in higher quality, more visibility an=
d therefore more motivation for people to contribute, and I believe also in=
 more deliverables rather than less as people will work towards clear goals=
 + be accepting if they miss them and they need to wait for the next releas=
e train.

As we will stay flexible, a fixed time time to begin with is better.

The other key part was about features selection, unlike what has been
done (or suggested in this thread), we should take what is done but
what we what is ready and desired. Desired as in tested (viable, BC,
QAs, etc.) and desired (RFC, votes, etc.).

A fixed time line also helps developers to catch the next band wagon
if they miss one, instead of pushing in half backed additions.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org