Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52660
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 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=wIZHXKs9xEWHM7ay5PZtZRSiSdsE3iRQGvgZi1if2udjPTf6f3/0PdMptfCCvcsNwN
         4dY2Q86uryjf+VN+Mu4WLSTtkyPycRKQfXJCULhBEx4V0pm3oAGoybkBXj2aP22bIydu
         LUFR7ppdOyiCn/fpp86iJVt2HdJGhv2AXN9Z8=
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.02.1106011230270.9040@whisky>
References: <BANLkTim2Tbw+9egfrmrYfeZfNNwYWcg4dg@mail.gmail.com>
	<alpine.DEB.2.02.1106011230270.9040@whisky>
Date: Wed, 1 Jun 2011 13:55:11 +0200
Message-ID: <BANLkTikWOWwpDrGvpQCTqS15ygCjH1PD_g@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Final version, RFC release process
From: pierre.php@gmail.com (Pierre Joye)

>> =A0 =A0 =A0 * running the various test suites (phpt, custom real life te=
sts,
>> =A0 =A0 =A0 platform specific tests). Some tests need a day to run
>> =A0 * November, Final
>> =A0 =A0 * Last RC taken as final, golden release (no change between the =
last RC and the final version)
>
> TBH, I think 6 months is too much between first alpha and release.
> Because we'd only have 6 months for a "normal cycle".

That's a max and reasonable time frame based on what we had in the
past and based on discussions with the devs actually doing the work.
So what if we make it before? a wonder! But at least there is a max
deadline.


> One issue with it though, the page that lists all the RFCs isn't
> maintained, and status isn't always updated. That needs to be done
> otherwise =A0we get to "oh, is this implemented yet?"

help welcomes.

>> Features can use branch(es) if necessary, doing so will minimize the
>> impact of other commits and changes on the development of a specific
>> feature (or the other way 'round). The shorter release cycle also
>> ensures that a given feature can get into the next release, as long as
>> the RFC has been accepted.
>
> I would word "can use branches if necessary" stronger, like "can use
> branches if *absolutely* necessary". The reason why, is that it is a good
> idea to get as many people familiar with new code. Of course, if there
> is a lot of ongoing work then a feature branch helps, but it should be
> merged into trunk as soon as it compiles (and doesn't break any test
> case) for peer review and more testing.


do not see a reason to change this part, it is self explaining and if
a developer likes to use an extra branche, then it is up to him as he
maintains that code anyway, at least for the development period.

>> The change to what we have now is the voting process. It will not
>> happen anymore on the mailing list but in the RFCs directly, for
>> php.net members, in an anonymous way (who votes what won't be made
>> public).
>>
>> The question for this section is about who will be allowed to vote:
>> =A0 * php-src (yes, no)
>> =A0 * php-doc (yes, no)
>> =A0 * qa, *phpt (yes, no)
>> =A0 * other sub projects like pear (yes, no)
>>
>> NB: the poll plugin will be installed shortly
>
> A few things here that I don't like. First of all, I think voting
> *should* be public.

Please read the RFC.

>> =3D=3D=3D=3D=3D Feature(s) preview release, solving the experimental fea=
tures =3D=3D=3D=3D=3D

> Isn't a feature preview just a snapshot or (the first) alpha?

no, and it may not be ready in time for a given release. And that
allows us to show something at any time to get more feedbacks from
users about a given complex or big feature/change without taking the
risk to break a given normal release. That sounds like a good solution
and can be done at any time.



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org