I'm just not sure why the release process has to be discussed right at the
moment and why you ask me to throw away everything how it is being done in
that release process that is not defined by me but proven to bring success
and is being done for long time. If you have concerns and suggestions to
the
release process, please initiate a discussion about it ASAP. But please
don't ask me to change the planned steps right at the second, it is
inconvenient and won't happen because it won't lead to anything good for
the
release itself.
Thanks
Anatol
Just a few words to say that delaying php 7 a few hours is not so important
for me..
My main concern is about which php version will be included in the next
Ubuntu 16.04 LTS!
At present, I use 12.04 LTS with php 5.3.10 .
and I will switch to 16.04 LTS about 6 months after it is released.. and
this until 20.04 + 6 months..
And I do not wish to stick with php 5.x until 2021 !!!!!!
So waiting a few hours is not a big effort!
If some of you are able to do some lobbying with ubuntu people, start it
before it is too late..
It seems (as I googled a bit) that they are not likely to include php7 in
16.04 LTS!
pk
I'm just not sure why the release process has to be discussed right at the
moment and why you ask me to throw away everything how it is being done in
that release process that is not defined by me but proven to bring success
and is being done for long time. If you have concerns and suggestions to
therelease process, please initiate a discussion about it ASAP. But please
don't ask me to change the planned steps right at the second, it is
inconvenient and won't happen because it won't lead to anything good for
therelease itself.
Thanks
Anatol
Just a few words to say that delaying php 7 a few hours is not so important
for me..My main concern is about which php version will be included in the next
Ubuntu 16.04 LTS!At present, I use 12.04 LTS with php 5.3.10 .
and I will switch to 16.04 LTS about 6 months after it is released.. and
this until 20.04 + 6 months..And I do not wish to stick with php 5.x until 2021 !!!!!!
So waiting a few hours is not a big effort!
If some of you are able to do some lobbying with ubuntu people, start it
before it is too late..It seems (as I googled a bit) that they are not likely to include php7 in
16.04 LTS!
I don't remember we've ever worked with Ubuntu teams.
We, PHP, are not distros maintainers.
Those later do whatever they want, sometimes working in sync with us.
And remember if you don't agree with your actual package maintainers
decisions, you still can switch distro.
Julien.Pauli
Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:
Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
--
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing windows
binaries there were no binary distributions for php windows.
nowadays there are a bunch of other places for people to fetch their
windows binaries (the MS web platform installer, apachelounge, the numerous
wamp stacks, etc.) so there are less reasons to do so, but this is how we
did for years, and changing this would require a discussion and probably an
RFC and vote.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing windows
binaries there were no binary distributions for php windows.
It might be less needed than before. I am compiling OpenSSL 1.0.2e for
Windows at the moment. Guess that Anatol is doing the same.
Jan
Jan Ehrhardt phpdev@ehrhardt.nl schrieb am Do., 3. Dez. 2015 17:04:
Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing windows
binaries there were no binary distributions for php windows.
It might be less needed than before. I am compiling OpenSSL 1.0.2e for
Windows at the moment. Guess that Anatol is doing the same.
Jan
--
To unsubscribe, visit: http:// http://www.php.net/unsub.phpwww.php.net
http://www.php.net/unsub.php/ http://www.php.net/unsub.phpunsub.php
http://www.php.net/unsub.php
Seems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.
Does it work for you?
Regards, Niklas
Niklas Keller in php.internals (Thu, 03 Dec 2015 17:39:35 +0000):
Seems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.
On Windows you don't do 'make test', you do
N:\OpensslVC14.x64\openssl>nmake -f ms\ntdll.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all tests
and
N:\OpensslVC14.x64\openssl>nmake -f ms\nt.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all tests
I had some trouble adding the applink. With the standard FIPS 140-2 build
scripts it stopped with a "Do not know how to make tmp32\applink.obj".
Copying the tmp32dll\applink.obj to tmp32 proved to be the solution.
I am now running the subversion test.
https://www.apachelounge.com/viewtopic.php?t=6359
Jan
With the holiday season quickly approaching and with more developers taking
time off as a result, I would like to again propose (suggest) that January
2016 release maybe more appropriate. I would not wish for PHP development
to rush to release and I feel it would give everyone more time to review
any outstanding issues (less pressure).
Niklas Keller in php.internals (Thu, 03 Dec 2015 17:39:35 +0000):
Seems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.On Windows you don't do 'make test', you do
N:\OpensslVC14.x64\openssl>nmake -f ms\ntdll.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all testsand
N:\OpensslVC14.x64\openssl>nmake -f ms\nt.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all testsI had some trouble adding the applink. With the standard FIPS 140-2 build
scripts it stopped with a "Do not know how to make tmp32\applink.obj".
Copying the tmp32dll\applink.obj to tmp32 proved to be the solution.I am now running the subversion test.
https://www.apachelounge.com/viewtopic.php?t=6359
Jan
Disregard. I now see that a completed build was released.
With the holiday season quickly approaching and with more developers
taking time off as a result, I would like to again propose (suggest) that
January 2016 release maybe more appropriate. I would not wish for PHP
development to rush to release and I feel it would give everyone more time
to review any outstanding issues (less pressure).Niklas Keller in php.internals (Thu, 03 Dec 2015 17:39:35 +0000):
Seems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.On Windows you don't do 'make test', you do
N:\OpensslVC14.x64\openssl>nmake -f ms\ntdll.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all testsand
N:\OpensslVC14.x64\openssl>nmake -f ms\nt.mak test
....
client authentication
server authentication
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA
depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2
TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
1 handshakes of 256 bytes done
passed all testsI had some trouble adding the applink. With the standard FIPS 140-2 build
scripts it stopped with a "Do not know how to make tmp32\applink.obj".
Copying the tmp32dll\applink.obj to tmp32 proved to be the solution.I am now running the subversion test.
https://www.apachelounge.com/viewtopic.php?t=6359
Jan
Jan Ehrhardt phpdev@ehrhardt.nl schrieb am Do., 3. Dez. 2015 17:04:
Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing windows
binaries there were no binary distributions for php windows.It might be less needed than before. I am compiling OpenSSL 1.0.2e for
Windows at the moment. Guess that Anatol is doing the same.Jan
--
To unsubscribe, visit: http:// http://www.php.net/unsub.phpwww.php.net
http://www.php.net/unsub.php/ http://www.php.net/unsub.phpunsub.php
http://www.php.net/unsub.phpSeems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.Does it work for you?
The release tarball builds fine against openssl-1.0.1k on Debian-jessie
for me. I haven't tested 1.0.2e yet. Waiting on
https://launchpad.net/debian/+source/openssl/ to get 1.0.2e.
-Rasmus
Yes, releases have been repackaged, see
https://mta.openssl.org/pipermail/openssl-announce/2015-December/000051.html
Regards, Niklas
2015-12-03 21:47 GMT+01:00 Rasmus Lerdorf rasmus@lerdorf.com:
Jan Ehrhardt phpdev@ehrhardt.nl schrieb am Do., 3. Dez. 2015 17:04:
Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing
windows
binaries there were no binary distributions for php windows.It might be less needed than before. I am compiling OpenSSL 1.0.2e for
Windows at the moment. Guess that Anatol is doing the same.Jan
--
To unsubscribe, visit: http:// http://www.php.net/unsub.phpwww.php.net
http://www.php.net/unsub.php/ http://www.php.net/unsub.phpunsub.php
http://www.php.net/unsub.phpSeems like a failed release, make test doesn't work for OpenSSL 1.0.2e.
Heared other people have other issues on 1.0.1 as well.Does it work for you?
The release tarball builds fine against openssl-1.0.1k on Debian-jessie
for me. I haven't tested 1.0.2e yet. Waiting on
https://launchpad.net/debian/+source/openssl/ to get 1.0.2e.-Rasmus
Yes, releases have been repackaged,
see https://mta.openssl.org/pipermail/openssl-announce/2015-December/000051.html
Ah, I misread. I thought you meant our php-7.0.0 tarball was a failed
release.
Niklas Keller in php.internals (Thu, 3 Dec 2015 21:58:18 +0100):
Yes, releases have been repackaged, see
https://mta.openssl.org/pipermail/openssl-announce/2015-December/000051.html
Anyway, I got it to build and all tests passed. So did Anatol, I presume.
And the subversion tests with this release showed no regression, compared
to 1.0.2d:
Summary of test results:
2171 tests PASSED
109 tests SKIPPED
38 tests XFAILED (1 WORK-IN-PROGRESS)
SUMMARY: All tests successful.
This is a good indication that it will work with Apache as well. To be
sure, I will do things once again with the repackaged sources in due time.
Jan
On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann sebastian@php.net
wrote:Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
--
loaded question, I think it would worth splitting the discussion into a
separate thread.
my understanding is that at the time when we started distributing windows
binaries there were no binary distributions for php windows.
nowadays there are a bunch of other places for people to fetch their
windows binaries (the MS web platform installer, apachelounge, the
numerous
wamp stacks, etc.) so there are less reasons to do so, but this is how we
did for years, and changing this would require a discussion and probably
an
RFC and vote.
All of them use php.net. all.
There are special builds but for binary compatibility reasons, we manage to
unify them all.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, are not distros maintainers.
Well said. But why, then, do we provide Windows binaries?
I am sure I can find many mails, private or public, where you, as one out
of many, asked for it.
Now forget the hype and complains, it is getting released. Thanks.
Hi!
Well said. But why, then, do we provide Windows binaries?
Windows as a platform is different from Linux/Mac in several aspects: in
how easy it is to obtain binary (without php.net ones), how easy it is
to build one and how easy it is to an average user of the platform to do
that (building the binary from VCS version), and how much of the
platform the binary would cover when built. In combination, I think it
makes sense that we have Windows binaries but not, say, Linux (which
Linux?) binaries.
--
Stas Malyshev
smalyshev@gmail.com
Am 04.12.2015 um 00:09 schrieb Stanislav Malyshev:
Windows as a platform is different from Linux/Mac in several aspects
True. But why does the PHP Project have to provide Windows binaries on
php.net? Microsoft should be treated as any other downstream vendor: let
them build their binaries on their infrastructure and let them distribute
their binaries through their channels.
Again, my intention is not to "bash Microsoft". I appreciate and
respect everything they have done to make PHP on Windows more robust.
I just think that the PHP project would be better off to focus on
one release artifact: the source tarball.
Am 04.12.2015 um 00:09 schrieb Stanislav Malyshev:
Windows as a platform is different from Linux/Mac in several aspects
True. But why does the PHP Project have to provide Windows binaries on
php.net? Microsoft should be treated as any other downstream vendor: let
them build their binaries on their infrastructure and let them distribute
their binaries through their channels.Again, my intention is not to "bash Microsoft". I appreciate and
respect everything they have done to make PHP on Windows more robust.
I just think that the PHP project would be better off to focus on
one release artifact: the source tarball.
I would much appreciate if you stop hijack this thread with irrelevant
topics. Less important now but doing such things on the 7 release day was
not the best idea ever.
It could be acceptable if the qa part of the thing was not totally ignore
despite numerous reminder.
Last but not least, it seems there is a lack of knowledge and up-to-date
information about what is done where and why. Informing yourself would kill
90% of this argument. Or ask in doubt.
Windows as a platform is different from Linux/Mac in several aspects
True. But why does the PHP Project have to provide Windows binaries on
php.net? Microsoft should be treated as any other downstream vendor: let
them build their binaries on their infrastructure and let them distribute
their binaries through their channels.
I think the problem in the past has been that simply compiling on a
windows machine required both proprietary software and an understanding
of areas that a new user would not normally encounter. Things have
changed and we can download a free environment to create a windows build
almost as easily as building on any Linux distribution. That ONLY works
because Pierre and others have sorted out all the problems with the
build process, and the binaries are almost a free result of the QA
process. It would be nice if Apache was also available as an official
windows build since that can still be difficult to build privately on
windows and is the main reason ApacheLounge came into existence.
Yes providing windows binaries is not essential but it does at lease
ensure that one is helping a windows php newbie one knows exactly what
they have installed. Personally I've migrated to only running PHP on
Linux these days but I still have to support windows only sites and
appreciate the binary builds.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Windows as a platform is different from Linux/Mac in several aspects
True. But why does the PHP Project have to provide Windows binaries on
php.net? Microsoft should be treated as any other downstream vendor:
let
them build their binaries on their infrastructure and let them
distribute
their binaries through their channels.I think the problem in the past has been that simply compiling on a
windows machine required both proprietary software and an understanding
of areas that a new user would not normally encounter. Things have
changed and we can download a free environment to create a windows build
almost as easily as building on any Linux distribution. That ONLY works
because Pierre and others have sorted out all the problems with the
build process, and the binaries are almost a free result of the QA
process. It would be nice if Apache was also available as an official
windows build since that can still be difficult to build privately on
windows and is the main reason ApacheLounge came into existence.Yes providing windows binaries is not essential but it does at lease
ensure that one is helping a windows php newbie one knows exactly what
they have installed. Personally I've migrated to only running PHP on
Linux these days but I still have to support windows only sites and
appreciate the binary builds.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
If anyone feels strongly one way or another about providing binary releases
for different platforms; why not create an RFC and vote on it?
~C
Am 04.12.2015 um 00:09 schrieb Stanislav Malyshev:
Windows as a platform is different from Linux/Mac in several aspects
True. But why does the PHP Project have to provide Windows binaries on
php.net? Microsoft should be treated as any other downstream vendor: let
them build their binaries on their infrastructure and let them distribute
their binaries through their channels.Again, my intention is not to "bash Microsoft". I appreciate and
respect everything they have done to make PHP on Windows more robust.
I just think that the PHP project would be better off to focus on
one release artifact: the source tarball.
While I'd love to share your view on this I think it's just unrealistic
in regards to ease of use towards anyone who's not a hardcore windows
developer.
a) building a php.net release tarball on a freshly installed
Ubuntu/CentOS/Debian/whatever box:
- it's literally 1 copy/pastable command line to install all
dependencies, then unzip, configure make.
b) building this on Windows:
- to be honest, I don't even know how many steps exactly are involved,
I've given up years ago. And in my team I am usually the one most
confident to develop anything in any language on Windows.
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development. Yes, this could be alleviated with builds from external
sources, but most language teams release for "more platforms". And I
stand to what I said above. On Linux (and maybe also on OS X?) you can
get 90% of users non-versed in C development to build their PHP quite
easily, on Windows.. maybe possible, but not worth the hassle.
Greetings,
Florian
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development.
Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?
On Fri, Dec 4, 2015 at 11:01 AM, Sebastian Bergmann sebastian@php.net
wrote:
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development.Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?
Because you're asking PHP to somehow influence Microsoft to change how they
operate. That's simply not something they do or have ever done AFAIK. I
don't know of a single piece of OSS that Microsoft builds and supplies
binaries for, what makes you think they will start doing it just for PHP?
Python, Mozilla, Pidgin, VLC and I'm sure many others provide their own
binaries for Windows, they are not supplied by Microsoft. Why would PHP be
any different?
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development.Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?
Sorry Sebastian but this is getting annoying now.
What is the problem? 2h delay due to openssl and absolutely not about
windows? That this build and tests have found numerous issues, some other
critical, on most supported platforms (read: not only windows). Or
something else?
We do that since more than 13 years and all of a sudden it is a problem?
Big enough to annoy the RMs the day they have dozen of other things to deal
with? Seriously?
It has been a community efforts to support Windows binaries on windows
along all dependencies used by php. Since years.
The initial effort was to ensure binaires compatibility for Windows. Before
that we, the developers doing the support, QA, etc spent an insane amount
of time debugging issues caused by incompatible binaries.
In the meantime, it happens that Microsoft fund the windows support through
Anatol, Steve, Matt and me. This support goes way behind windows only. Be
from a QA point of view, portability (all platforms), fixing the core, core
exts as well as other exts, on all supported platforms. Including the first
automated perf regression testing or static analyze. Along other amazingly
useful reports.
It became part of the release process years ago. A natural and painless
move. Beneficial to all php users (read: windows or not). I never saw you
jumping in and complain about that. And again, the QA part of this process
is a key point. It should be something you, especially you, must understand.
You want to kick out windows binaries of php.net? Go ahead with a rfc. If
you have nothing constructive to do and so much spare time to do something
as destructive and poisoning as that, even if the rfc fails.
On the other hand, I would suggest you in the most friendly way to consider
to contribute to the core in other ways.
Cheers,
Pierre
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development.Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?
I think we're looking at the same problem from different directions :)
Many languages offer something for different platforms (see below), I
wonder why for example http://php-osx.liip.ch/ is a dedicated project
and no one (or did someone?) try to invite them (or are there better
alternatives?) to be an official part of php.net? (The formal answer
probably is "we only support the release tarball, as downloaded from
php.net - but that's not because users don't matter, just to keep the
reproducability of bugs consistent. And I think on Windows and OS X this
could warrant having blessed builds for ease of use.)
So to answer your question: We're treating Windows differently because
it's badly needed. And neither RHEL nor Fedora or Ubuntu need that.
Greetings,
Florian
3 quick examples:
python.org:
https://www.python.org/downloads/
Looking for Python with a different OS? Python for Windows,
Linux/UNIX, Mac OS X, Other
rust-lang.org:
https://www.rust-lang.org/downloads.html
Downloads for 3 platforms
ruby-lang.org:
https://www.ruby-lang.org/en/documentation/installation/
For Windows, just a link to RubyInstaller
Hi Florian,
Florian Anderiasch wrote:
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is kind of
sticking the finger to everyone using Windows for PHP (not the language)
development.Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?I think we're looking at the same problem from different directions :)
Many languages offer something for different platforms (see below), I
wonder why for example http://php-osx.liip.ch/ is a dedicated project
and no one (or did someone?) try to invite them (or are there better
alternatives?) to be an official part of php.net? (The formal answer
probably is "we only support the release tarball, as downloaded from
php.net - but that's not because users don't matter, just to keep the
reproducability of bugs consistent. And I think on Windows and OS X this
could warrant having blessed builds for ease of use.)So to answer your question: We're treating Windows differently because
it's badly needed. And neither RHEL nor Fedora or Ubuntu need that.
I think it's worth pointing out that for OS X, Apple themselves
distribute PHP, and in addition there's decent community package
managers (Homebrew's the one I like), and it's easy to build yourself.
--
Andrea Faulds
http://ajf.me/
Hi Florian,
Florian Anderiasch wrote:
Am 04.12.2015 um 18:53 schrieb Florian Anderiasch:
I hate to say it, but not providing an official Windows build is
kind of
sticking the finger to everyone using Windows for PHP (not the
language)
development.Sorry, but that does not explain the special treatment of Windows.
Red Hat provides official PHP binaries for RHEL and Fedora. Ubuntu
provides official PHP binaries for Ubuntu. etc. Why should Microsoft
not provide the official PHP binaries for Windows?I think we're looking at the same problem from different directions :)
Many languages offer something for different platforms (see below), I
wonder why for example http://php-osx.liip.ch/ is a dedicated project
and no one (or did someone?) try to invite them (or are there better
alternatives?) to be an official part of php.net? (The formal answer
probably is "we only support the release tarball, as downloaded from
php.net - but that's not because users don't matter, just to keep the
reproducability of bugs consistent. And I think on Windows and OS X this
could warrant having blessed builds for ease of use.)So to answer your question: We're treating Windows differently because
it's badly needed. And neither RHEL nor Fedora or Ubuntu need that.I think it's worth pointing out that for OS X, Apple themselves
distribute PHP, and in addition there's decent community package
managers (Homebrew's the one I like), and it's easy to build yourself.
php-osx.liip.ch is a fork of marc liyanage's entropy php back then when
he stopped supporting it. We used and extended it in-house and put it
into public just to give back to the community. We never thought this
should be an "official" PHP release, as andrea said, there are many ways
to install a recent PHP on OS X, ours is just one way.
Nowadays we mostly use VMs for development, so don't really actively use
our own binaries, but doing the update now and then is not a big effort,
therefore we still update it. But don't invest too much time anymore, if
some exotic extension doesn't work. But we encourage everyone to contribute.
I'm fine with having that outside of PHP.net and concentrating the
efforts of the PHP community on the source releases (and Windows ;))
Greetings
chregu
--
Liip AG // Limmatstrasse 183 // CH-8005 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x1575A89B
Hi Florian,
I think it's worth pointing out that for OS X, Apple themselves
distribute PHP, and in addition there's decent community package
managers (Homebrew's the one I like), and it's easy to build yourself.
I'm fine with having that outside of PHP.net and concentrating the
efforts of the PHP community on the source releases (and Windows ;))
Hi,
I was in no way trying to encourage any change for anyone that's not
intended ;)
My experiences in the past though showed me that "web developers" doing
only PHP and JavaScript development very often are neither interested
nor have the knowledge to easily build PHP on either Windows or OS X.
(Yes, it sounds like the typical cliche that only the Linux users know
how to do that by default, but it absolutely matches what I saw.)
And afaik Apple only delivers one version per OS X release, so that only
solves some problems. My point was that it's very easy to build on Linux
and I've seen a share of problems on both Windows and OS X for people
who haven't invested some effort. (Maybe more effort than necessary.)
But I did forget about Homebrew and maybe back then this was a bigger
problem than it is now.
Gretings,
Florian
-----Message d'origine-----
De : julienpauli@gmail.com [mailto:julienpauli@gmail.com] De la part de Julien Pauli
Envoyé : jeudi 3 décembre 2015 16:11
And remember if you don't agree with your actual package maintainers decisions, you still can switch distro.
Julien.Pauli
It is not always you that are in charge of deciding which distribution is to be used on a computer equipment set ...
... and when upgrades are to be done...
It can be people you work for...
pk
Pascal KISSIAN wrote on 03/12/2015 13:30:
My main concern is about which php version will be included in the next
Ubuntu 16.04 LTS!
I wouldn't be surprised if most distros, whenever they add it to their
primary package repo, will package php7 separately from php5, and allow
them to be selected and installed side-by-side in various ways.
In fact, I'd be surprised if they didn't do that, since most already
had it set up for //php4 vs php5.
It therefore comes down to whether a version of the php7 package is
blessed as part of "Xenial Xerus", or whether you'll have to get it from
a PPA (e.g. https://launchpad.net/~ondrej/+archive/ubuntu/php-7.0)
I believe Debian / Ubuntu's stabilisation process is fairly strict and
well-defined, so lobbying from "upstream" (i.e. people on this list)
isn't likely to have a huge impact. They don't even follow the official
point releases, preferring to fork from a well-tested point and maintain
their own set of patches.
Regards,
Rowan Collins
[IMSoP]