On Fri, Jan 31, 2014 at 9:21 PM, Zeev Suraski <[email protected]> wrote:
> > -----Original Message-----
> > From: Johannes Schlüter [mailto:[email protected]]
> > Sent: Friday, January 31, 2014 2:55 PM
> > To: Ulf Wendel
> > Cc: [email protected]
> > Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
> > length and integer
> >
> > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel wrote:
> > > Am 31.01.2014 13:36, schrieb Johannes Schlüter:
> > > > I think adding this patch to 5.x therefore would be quite some
> > > > bending of that rule and that combined with the fact that it is late
> > > > makes me believe that proposing this for 5.6 is illegal.
> > >
> > > Are you saying the RFC is 'illegal' ? If the subject proposed is not
> > > allowed, it would make litte sense collecting votes.
> >
> > I think the RM has to reject this from 5.6 independently from the voting
> > result as he is bound by the release process RFC.
>
>
> All,
>
> I have to add something here.
>
> Many of the people voting on that RFC have never ever contributed as much
> as
> a single line of code into the PHP source tree, and a couple have literally
> contributed low-single-digit patches.
> Incidentally, as far as I could tell, all of them[*] voted in favor of the
> proposed changes (i.e. source compatibility breakage).
>
> Even though having non-code-contributors makes a lot of sense for decisions
> regarding the language's features and we built in support for it in the
> voting RFC, in my opinion, it makes no sense at all for people who have no
> stake at the development of the language's source code to weigh in on how
> that code is written. Personally I didn't expect we'd be voting on things
> like that (implementation style) back when I was involved in the voting
> RFC,
> but perhaps it's time to amend it a bit.
>
> If you fall in that category, please do the right thing and delete your
> vote.
>
Hi Zeev,
I think that this vote also makes sense for maintainers of PECL extensions
as they will need to do lots of work.
I am aware what the patch does and how much work I will need to do in my
extensions. I actually did the openssl part of the 64bit patch just to see
what changes will be required for my crypto ext which also is an openssl
wrapper. And yes it will require lots of changes. Probably the most time
consuming part of the porting (that wasn't mentioned here) is looking to
the different versions of the libs and testing how it affects the
extension. There are sometimes types changes between different versions of
libs which can result in nasty bugs. For example the size_t change could
even result to some security issues if it's not handled properly.
The reason why I voted YES is that I don't see any difference if the patch
is merged now or in the future. The work will need to be done anyway. It
will just require more time that will need to be spent on maintaining the
64bit branch if the patch is merged later.
Thanks
Regards
Jakub