Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.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=ELPSOPi8ZmrncZ6S5I3GAPb7jCdhRJ/7h1ni3wcaFI+A/WsiyVV8q3SxOxGyVod9Ze
         fCx5GSSVKiEWiVc8llyrpn5wMyp4eToteEYzWUBZz8eEHcHEiXoaD73p9XV8PA9zNXwX
         0pNkWOkYB7h99U8+Ki6aOI/8bWVXTxh6Vlk7U=
MIME-Version: 1.0
In-Reply-To: <58.B0.08358.D0DCBEC4@pb1.pair.com>
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com>
	<alpine.DEB.2.00.1011231002140.24401@kossu.derickrethans.nl>
	<AANLkTikpkcXr34ftFiJdpAUQZ2uVn7kkNr+DToB=9Bkq@mail.gmail.com>
	<alpine.DEB.2.00.1011231359100.24401@kossu.derickrethans.nl>
	<58.B0.08358.D0DCBEC4@pb1.pair.com>
Date: Thu, 25 Nov 2010 02:07:42 +0100
Message-ID: <AANLkTi=iYU+j1X1dpyVe1MpT=Uo5sY+XwUBcYrtm-ywc@mail.gmail.com>
To: "Matthew Weier O'Phinney" <weierophinney@php.net>
Cc: 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,

amen.

On Tue, Nov 23, 2010 at 3:17 PM, Matthew Weier O'Phinney
<weierophinney@php.net> wrote:
> On 2010-11-23, Derick Rethans <derick@php.net> wrote:
>> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>> > > All the rest you write in the RFC is basically already as we do it.
>> >
>> > yeah, maybe, but they aren't written down, accepted and well-known rul=
es, so
>> > you can forgot/misunderstand/bend them. :/
>>
>> And I don't think that is a bad thing. It's good to be able to be
>> flexible.
>
> A good artist is capable of great flexibility within the constraints of
> their medium. In the case of software releases, you can still have
> greate flexibility even with an existing release process. In many ways,
> having the process defined helps bring about creative solutions -- "if I
> want to get this in time for the release, what solution will work best?"
>
> I used to love the ad hoc nature of "we'll release when it's ready."
> However, having done quite a number of scheduled releases, I've found
> that:
>
> =A0* Predictability motivates developers. "Release is in 3 months? Okay,
> =A0 let's get rolling on this!"
>
> =A0* Knowing when the next release is coming also means that developers
> =A0 are more comfortable if they're unable to make the deadline. "I can't
> =A0 do it by this release, but I should have no trouble making the next."
>
> =A0* Less stressful for release managers. If the code isn't ready by the
> =A0 deadline, it's not merged to the branch, plain and simple.
>
> The status quo works great for those whom it serves. For everyone else,
> it stinks. There's no transparency, which leads to disenfranchisement.
>
> --
> Matthew Weier O'Phinney
> Project Lead =A0 =A0 =A0 =A0 =A0 =A0| matthew@zend.com
> Zend Framework =A0 =A0 =A0 =A0 =A0| http://framework.zend.com/
> PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org