Just stumbled over this one:
https://bugs.php.net/bug.php?id=60503
Time to remove some things in master?
--
Regards,
Mike
Hi all,
Just stumbled over this one:
https://bugs.php.net/bug.php?id=60503
Time to remove some things in master?
Site is down?
+1 for removing them.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Time to remove some things in master?
Site is down?
+1 for removing them.
What "obsolete" means in this case? Doesn't compile? Doesn't work? Works
just fine but is missing some features?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Time to remove some things in master?
What "obsolete" means in this case? Doesn't compile? Doesn't work? Works
just fine but is missing some features?
Good questions, but obviously nobody can answer them...
If those awkward strangers are eligible to be shipped with the
distribution, we don't even have to debate about things like bundling
phpdbg.
Maybe the reporter is just jealous, who knows?
--
Regards,
Mike
Hi!
Time to remove some things in master?
What "obsolete" means in this case? Doesn't compile? Doesn't work? Works
just fine but is missing some features?Good questions, but obviously nobody can answer them...
If those awkward strangers are eligible to be shipped with the
distribution, we don't even have to debate about things like bundling
phpdbg.Maybe the reporter is just jealous, who knows?
The policy to date was very flexible with SAPIs as one has to enable it.
Whether it is stable, maintained etc never played a big role.
The other argument was that there is no way to distribute sapis outside the
core.
I would prefer to remove dead cows (and this one is definitively one).
Cheers,
Pierre
Hi,
On Fri, Dec 6, 2013 at 5:25 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Time to remove some things in master?
Site is down?
+1 for removing them.What "obsolete" means in this case? Doesn't compile? Doesn't work? Works
just fine but is missing some features?
Since server source is not available, it cannot compile.
I think it's safe to remove.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Since server source is not available, it cannot compile.
I think it's safe to remove.
You don't need the sources to build, an installation with approproiate
header files and libraries would be sufficient.
--
Regards,
Mike
Since server source is not available, it cannot compile.
I think it's safe to remove.You don't need the sources to build, an installation with approproiate
header files and libraries would be sufficient.
Just FYI, this does still build fine using sources from
http://web.archive.org/web/20070607203241/http://www.ashpool.com/continuity/index.html
...
Never heard of it ...
Cheers
Joe
Just stumbled over this one:
https://bugs.php.net/bug.php?id=60503
Time to remove some things in master?
--
Regards,
Mike
Possibly relevant; in case you missed it there was a small discussion
on removing obsolete SAPIs earlier this year.
Thread was started by Terry Ellison on August 19th if you want to check it out.
[PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
Just stumbled over this one:
https://bugs.php.net/bug.php?id=60503
Time to remove some things in master?
--
Regards,
Mike
Possibly relevant; in case you missed it there was a small discussion
on removing obsolete SAPIs earlier this year.Thread was started by Terry Ellison on August 19th if you want to check it out.
[PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
Thanks Leigh,
Looking back at the thread, I made the mistake of wandering off topic,
but the points in my O/P are still lying there unanswered:
- Obsolete SAPI list:
Examples of what I am talking about are SAPIs with no clear evidence
of active support (I've listed the last non-bulk change in brackets to
give a measure of the level of support):
aolserver (2008), caudium (2005), continuity (2004), phttpd (2002),
pi3web (2003), roxon (2002), thttpd (2002), tux (2007), webjames
(2006)
- Obsolete OS support:
Likewise in the Zend, TSRM, ext/opcache ... sources, there is
conditional code dependent on BeOS, __sgi, osf, IRIX, PI3WEB,
GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs
that are no longer actively supported.
We've had "make test" feedbacks for years. Is this data ever mined to
validate that SAPI and OS build variants are being actively carried out
tracking currently supported OSes? Do we have an active deprecation
process so that we can cull dead code?
There's too much ifdef source and even some compiled logic -- mainly in
the Zend Engine and in the SAPIs, but also extensions -- that has
probably not been covered in testing since at least the 5.2 timescales.
If we never exercise and validate code, then isn't time to at least
actively deprecate it in 5.6 so that it can be removed in a future release?
Regards
Terry Ellison
- Obsolete OS support:
Likewise in the Zend, TSRM, ext/opcache ... sources, there is
conditional code dependent on BeOS, __sgi, osf, IRIX, PI3WEB,
GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs
that are no longer actively supported.
Removing from the source any OS that PHP no longer supports seems like
a no-brainer. But if the OS is no longer actively supported by its
owner, that isn't the same as not supported by PHP, right? For
example, will the IIS 5.1 docs be removed at XP's end date (4/8/2014),
or some known period after that? And IRIX is still supported by SGI
AFAIK (we have a compute cluster running it, though no PHP there).
I'm not taking a side for or against any one of these. I'm just
wondering what standards dictate when PHP is not longer supported on a
given OS: a separate RFC and vote for each OS is a fine answer, even
though I can't vote! But not having compiled for an OS in a while
shouldn't be reverse-engineered as having voted to remove support,
know what I mean?
- Obsolete SAPI list:
Examples of what I am talking about are SAPIs with no clear evidence
of active support (I've listed the last non-bulk change in brackets to
give a measure of the level of support):
aolserver (2008), caudium (2005), continuity (2004), phttpd (2002),
pi3web (2003), roxon (2002), thttpd (2002), tux (2007), webjames
(2006)
Not a deeply held objection... but as a long-ago Roxen fan, I have to
question pushing a SAPI for removal based only on the date of the
SAPI's last touch. If the target server also hasn't been updated in
a long time and is on a supported OS, that SAPI-server combo is 99%
sure to still work. And it's perhaps overly strict to say that someone
who is still nursing an old HTTPd can't use the latest PHP features
just because we didn't feel like shipping the bridge anymore.
Unfortunately, getting usage stats for most of those servers is next
to impossible unless someone pipes up and says a certain widely
released app (I'm thinking stuff like server management utilities) may
want to take advantage of later PHPs. There might be some "white
label" webmail packages whose operators don't even remember that
they're based on one of those servers. I do doubt there are more than
a handful of general-purpose public-facing sites using them, though.
-- Sandy