Hello,
I've been watching the bug database for issues coming in for PHP7, and
there have been far fewer than I was expecting, which is nice.
However there are lots of issues open from 'a while ago' that are
either not really bug requests, or are too old to investigate.
I don't think having them kept open is providing any value, and it
makes it harder to find actual issues that need fixing in the issue
database, so I'd like to close some of them.
Obviously me just going through and closing issues en masse might
ruffle some feathers. Below is a list of some that are either not
bugs, or are too old to investigate. (e.g. A crash bug on PHP 4.3.9 is
not something that anyone should be looking at.)
If anyone thinks they all ought to be kept open, that could be
discussed on list, but I would really like to avoid discussing each
one individually on list, as I don't think that would be productive.
If anyone with wants to keep any of these issues open, please could
you assign them to yourself? Or leave a comment on the issue saying
that it needs to be kept open. Otherwise in a couple of days I'll go
through and close these, to make the list of open bugs be 1% smaller.
cheers
Dan
Small feature request
https://bugs.php.net/bug.php?id=7930 list() constructor reference assignment
https://bugs.php.net/bug.php?id=12501 Implement authen/authz handler capability
https://bugs.php.net/bug.php?id=14523 Additional parameter for str_repeat()
https://bugs.php.net/bug.php?id=15972 strip_tags should allow
restricting the attributes on tags that are kept
https://bugs.php.net/bug.php?id=17090 Getting slices of associative arrays
https://bugs.php.net/bug.php?id=22593 Fuzzy string matching / agrep
https://bugs.php.net/bug.php?id=26433 Request for is_unique()
https://bugs.php.net/bug.php?id=27453 islamic calender functions
https://bugs.php.net/bug.php?id=28252 ncurses support without a cygwin install.
https://bugs.php.net/bug.php?id=28812 getgid/getuid usage
https://bugs.php.net/bug.php?id=30918 Add a "non-local" flag param to realpath
https://bugs.php.net/bug.php?id=31627 return statement should return
https://bugs.php.net/bug.php?id=32524 Advanced imploding
https://bugs.php.net/bug.php?id=34527 trim functions extension
https://bugs.php.net/bug.php?id=35276 exploding_wordwrap
https://bugs.php.net/bug.php?id=36940 Dynamic open_basedir restriction
not possible.
https://bugs.php.net/bug.php?id=38339 Wanted: Find included file first
in the script's path, than include_path option
https://bugs.php.net/bug.php?id=38437 substr() - slightly change its contract
https://bugs.php.net/bug.php?id=38684 How about an
array_key_walk_recursive() function?
https://bugs.php.net/bug.php?id=40182 Want a function strpos_all with
optional parameters
https://bugs.php.net/bug.php?id=40499 Add highlightning filter
https://bugs.php.net/bug.php?id=44530 Multi-dimensional foreach iterator?
https://bugs.php.net/bug.php?id=46384 expr() or continue;
https://bugs.php.net/bug.php?id=46725 strpos extensions with array
type parameters
https://bugs.php.net/bug.php?id=48072 wish: extra strtr features
similar to GNU strtr
https://bugs.php.net/bug.php?id=48154 Add optional paramter to
print_r() for basic (X)HTML output formatting
https://bugs.php.net/bug.php?id=48192 if structure inherit else
https://bugs.php.net/bug.php?id=49007 Add limit option to trim functions
https://bugs.php.net/bug.php?id=49903 Strip $ at beginning of variable
names for compact()
https://bugs.php.net/bug.php?id=50653 str_split sequence handling
https://bugs.php.net/bug.php?id=51335 Search first substring from list
https://bugs.php.net/bug.php?id=51574 Modify range() function to
support A to ZZZZ
https://bugs.php.net/bug.php?id=52124 Limit search inside $haystack by
new $length parameter
https://bugs.php.net/bug.php?id=52177 please implement recursive ksort
https://bugs.php.net/bug.php?id=52626 New magic method for procedural
calls on object.
https://bugs.php.net/bug.php?id=52575 Would like get_called_class()
without namespace.
https://bugs.php.net/bug.php?id=53170 Cannot substract Arrays
https://bugs.php.net/bug.php?id=55389 Feature suggestion for array_search
https://bugs.php.net/bug.php?id=55633 New argument $invert for array_filter()
https://bugs.php.net/bug.php?id=60908 add array_filter_recursive function
https://bugs.php.net/bug.php?id=61438 color_to_hex functionally
https://bugs.php.net/bug.php?id=61987 abbreviate "Y-m-d H:i:s" to Q
https://bugs.php.net/bug.php?id=62574 New operator for htmlspecialchars
https://bugs.php.net/bug.php?id=65098 A modified version of array_combine()
https://bugs.php.net/bug.php?id=66598 Consider picking up efforts for
Mono integration.
https://bugs.php.net/bug.php?id=67035 wish: str_ends() and str_begins()
https://bugs.php.net/bug.php?id=67659 Support array of delimiters in explode()
https://bugs.php.net/bug.php?id=67734 Add output escaping specifiers
to sprintf etc.
https://bugs.php.net/bug.php?id=68806 getopt is not able to detect
unknown arguments
Way too old to investigate
These might have been real issues, but are ancient.
https://bugs.php.net/bug.php?id=30788 Tomcat 5.0.28 crashes
https://bugs.php.net/bug.php?id=57735 Segfault on non-existant file
https://bugs.php.net/bug.php?id=57962 core dump
Need an RFC
These are bigger feature requests, and would need a complete RFC to
implement, however they should be discussed as RFCs not bugs.
https://bugs.php.net/bug.php?id=38569 override keyword requested
https://bugs.php.net/bug.php?id=38079 __copy magic method to increase
backwards compatibility
https://bugs.php.net/bug.php?id=38544 tryeach
https://bugs.php.net/bug.php?id=38608 File include control system
feature request
https://bugs.php.net/bug.php?id=38622 Proposed new security scheme for
shared hosting (safe mode substitute)
https://bugs.php.net/bug.php?id=39091 Need to force variables to be declared
https://bugs.php.net/bug.php?id=47933 Allow foreach to iterate
multiple arrays/objects similar to for syntax
https://bugs.php.net/bug.php?id=51598 String Objects?
https://bugs.php.net/bug.php?id=53159 Tolerant and Strict Variables
and functions
https://bugs.php.net/bug.php?id=59779 Support for unary minus
https://bugs.php.net/bug.php?id=60219 Option to disable php_engine if
file owner uid == getuid for webserver security
https://bugs.php.net/bug.php?id=62799 Parallel array processing
https://bugs.php.net/bug.php?id=64136 Better things handling - basic
variables should behave like object
https://bugs.php.net/bug.php?id=65750 Enabling factory constructors
https://bugs.php.net/bug.php?id=66022 operator overloading
https://bugs.php.net/bug.php?id=67409 Clone arguments
https://bugs.php.net/bug.php?id=69886 Addressing problems with
escaping (security)
https://bugs.php.net/bug.php?id=70087 Better string interpolation
https://bugs.php.net/bug.php?id=70231 Ability to set default params
within a functions arguments as an array/object
Just generate your config files
The nginx guys have the right idea for this. Limit the syntax
supported in config files, and tell people to generate their config
files from data.
https://bugs.php.net/bug.php?id=49375 Mass Virtual Hosting Enhancements
Hi!
However there are lots of issues open from 'a while ago' that are
either not really bug requests, or are too old to investigate.
Bug db also has feature requests. Which are fine, even if nobody does
them now, people may do in the future.
I don't think having them kept open is providing any value, and it
makes it harder to find actual issues that need fixing in the issue
database, so I'd like to close some of them.
Bug DB triage is a hard, long and often thankless work. I am very
thankful to you for spending your time on it.
bugs, or are too old to investigate. (e.g. A crash bug on PHP 4.3.9 is
not something that anyone should be looking at.)
I would say if it has reproduction, it should be checked on 5.5 still,
unless it is hard (like installing complex software, etc.). Just to be
sure. If no clear reproduction, close it.
For extensions (such as https://bugs.php.net/bug.php?id=57735) it's
harder because we don't know support status of those. It may be a real
bug but the extension is not maintained anymore.
If anyone with wants to keep any of these issues open, please could
you assign them to yourself? Or leave a comment on the issue saying
I'm not sure if we should be closing small feature requests. Unless it
is clear that we never, ever going to implement it (e.g. "Drop the $
prefix" would fit in the category ;)
But otherwise features should be pretty easy to filter out?
Anyway, I'll review the list and maybe change my mind :)
Those that do require RFC I think is fine to close. Maybe have a
standard text for that - like "This request describes a change that is
substantial enough to warrant an RFC. Please read <link> and submit an
RFC for the consideration for the community".
Thanks,
Stas Malyshev
smalyshev@gmail.com
Stanislav Malyshev wrote:
I don't think having them kept open is providing any value, and it
makes it harder to find actual issues that need fixing in the issue
database, so I'd like to close some of them.Bug DB triage is a hard, long and often thankless work. I am very
thankful to you for spending your time on it.
ACK
bugs, or are too old to investigate. (e.g. A crash bug on PHP 4.3.9 is
not something that anyone should be looking at.)I would say if it has reproduction, it should be checked on 5.5 still,
unless it is hard (like installing complex software, etc.). Just to be
sure. If no clear reproduction, close it.
For extensions (such as https://bugs.php.net/bug.php?id=57735) it's
harder because we don't know support status of those. It may be a real
bug but the extension is not maintained anymore.
For old bug reports it might be reasonable to change the status to
"Feedback" and ask, whether the issue still persists. This way the
report is likely going to end up with "No feedback", what's IMHO better
than "Closed" for such cases.
Those that do require RFC I think is fine to close. Maybe have a
standard text for that - like "This request describes a change that is
substantial enough to warrant an RFC. Please read <link> and submit an
RFC for the consideration for the community".
Good idea.
--
Christoph M. Becker
Hi!
For old bug reports it might be reasonable to change the status to
"Feedback" and ask, whether the issue still persists. This way the
report is likely going to end up with "No feedback", what's IMHO better
than "Closed" for such cases.
This is a good option too.
--
Stas Malyshev
smalyshev@gmail.com
Le 15/01/2016 19:53, Stanislav Malyshev a écrit :
Hi!
Those that do require RFC I think is fine to close. Maybe have a
standard text for that - like "This request describes a change that is
substantial enough to warrant an RFC. Please read <link> and submit an
RFC for the consideration for the community".
Not just a standard text, a new specific 'Require RFC' status too, so
that they can be easily retrieved.
Regards
François
Le 15/01/2016 19:53, Stanislav Malyshev a écrit :
Not just a standard text, a new specific 'Require RFC' status too, so that
they can be easily retrieved.
My initial reaction was to not like that idea....but it's grown on me.
It's a good solution to the backlog of issues that have been open for
years. It also makes it easier to handle new issues as they come up as
it is more appropriate to put new issues to that state than either
'closed' or 'wont fix'.
Who is able to a new 'Requires RFC' state to the bug tracker?
cheers
Dan
Hi!
It's a good solution to the backlog of issues that have been open for
years. It also makes it easier to handle new issues as they come up as
it is more appropriate to put new issues to that state than either
'closed' or 'wont fix'.Who is able to a new 'Requires RFC' state to the bug tracker?
As far as I can see, the only way to do it is to edit local database, so
somebody with shell access and DB password is needed.
--
Stas Malyshev
smalyshev@gmail.com
Le 15/01/2016 18:04, Dan Ackroyd a écrit :
If anyone thinks they all ought to be kept open, that could be
discussed on list, but I would really like to avoid discussing each
one individually on list, as I don't think that would be productive.If anyone with wants to keep any of these issues open, please could
you assign them to yourself?
Just assigned #14523 to me.
May I ask not to close feature requests ? #14523, for example, is
perfectly valid, even if dating back from 2001, and the requested
feature will be proposed in an RFC targeting 7.1.
The fact that the features were not implemented does not mean that the
FR is silly or obsolete. Closing such FR means, either 'implemented', or
'won't fix', which is generally not the case. So, I won't support
closing them en masse, just as a way to lower the number of open bugs.
Regards
François