Re: [RFC] 64 bit improvements, open questions
Hi Chris,
On Thu, January 23, 2014 21:01, Christopher Jones wrote:
>
>
> On 01/23/2014 12:47 AM, Anatol Belski wrote:
>
>> Hi Chris,
>>
>>
>> On Wed, January 22, 2014 20:36, Christopher Jones wrote:
>>
>>> The open issues (e.g. SAPI support) need to be resolved before
>>> starting the vote, so the RFC direction is obvious. Also the RFC
>>> needs to discuss proposed voting options, prior to starting the vote.
>>> Since that
>>> only gives a couple of days for discussion, I think you should delay
>>> the vote.
>> I'm not sure taking SAPI and ZPP topics out of the scope apart into new
>> RFCs would make any sense? But we probably can do multple votings in
>> the same RFC. That will be probably the most plausible solution to
>> decide, I gonna to update it :)
>
> I'm not a huge fan of multiple votes. I hope a consensus can be reached
> via the mail list first.
>>
>>> The porting doc compat/PECL_PORTING should be merged into the RFC
>>> (and
>>> removed from the tree) to capture as much information in the one place
>>> as possible.
>>>
>> I thought more like pick it out into a separate wiki page, as it's
>> porting specific. Still it will be linked from/to RFC, but the structure
>> were cleaner IMHO.
>
> It can be a separate section of the RFC. This will make the project's
> scope clear when it comes to voting on the RFC.
>
I've moved the SAPIs question into the new RFC
https://wiki.php.net/rfc/removal_of_dead_sapis
. I've got your point about
the multiple vote, however would let separate votes stay.
It's clear anyway that keeping old zpp specs makes the migration much more
easier. Another question there put to vote is "no macro renamings", so
that might change as well in the current patch. There are much more
potential voters than currently participate on this discussion, so any
consensus reached on the list were incomplete. Of course we see the
"trend".
For that reason I'd also let it stay as it is with the porting guide, as
it's written specifically for the current patch state. The vote can change
the patch, so rewriting all the docs again would make sense after it's
known how.
I just assume that the majority of the potential voters do follow this
discussions and could forge the opinion. That's why, I think it's better
to rely on the clear vote results with no room for ambiguity.
Regards
Anatol
Thread (15 messages)