Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.
When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.
It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.
With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.
I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.
I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.
I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.
After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.
Cheers
Joe
Hi Joe,
W dniu 08.01.2017 o 07:46, Joe Watkins pisze:
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.
Great job on cleaning up Pull Requests. I was really impressed to see
it dropping down from over 300 to about ~140.
When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.
Definitely, there was a similiar initiative about 2 years ago IIRC and
I think that cleaning up the bugtracker is always a good thing(tm). I
wasn't able to help with pull requests due to the lack of PHP internal
knowledge, but I would be able to help a little with bug reports.
It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.
I would basically close (probably "Suspend", to be more precise) each of
Feature Requests related to the PHP itself. It's not really used anymore
and if I'm right we rather prefer direct mail on php.internals and/or
pull request.
I even thought about disallowing new "Feature Requests" completely and
adding a message that bug tracker is not a suitable place anymore. This,
on the other hand, might be still used for other project types.
I can handle Feature Requests if you're OK with that, I think it should
help a little.
After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.Cheers
Joe
Thanks,
Maciej.
Am 08.01.2017 um 07:46 schrieb Joe Watkins:
I think any bug report opened against 4 and not updated is useless.
+1
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.
+1
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.
When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.
It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.
With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.
I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.
I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.
I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.
After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.
Cheers
Joe
As a general note: By convention the "Closed" state is only for bugs that
have been fixed or feature requests that have been implemented. If
something is not going to be fixed / implemented one of Won't Fix, Not a
Bug or Suspended should be used, as appropriate.
Nikita
Afternoon Nikita,
ACK, we should of course use appropriate status ... I have only closed a
few so far before I thought a discussion is probably in order, so no harm
done.
Cheers
Joe
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.Cheers
JoeAs a general note: By convention the "Closed" state is only for bugs that
have been fixed or feature requests that have been implemented. If
something is not going to be fixed / implemented one of Won't Fix, Not a
Bug or Suspended should be used, as appropriate.Nikita
Hi all.
Am 08.01.17 um 11:29 schrieb Nikita Popov:
Morning internals,
[…]With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.
I'd even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"
There might be issues that are still relevant, but IMHO it's easier to
reopen an issue when need arises than investing the manpower of checking
whether that's still an issue with PHP 7 or not.
Just my 0.02 €
Andreas
PS: Ping me when I shall give a hand at that task!
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Hi!
I'd even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"
Lots of people run 5.5 now. I'd say at least about 2/3 of PHP users in
the field are now < 5.6. Blanket closing all those bugs with "wontfix"
sound non-productive to me - I'd rather at least give people chance to
update the info. Many extension bugs were transferred from 5.x to 7.x as
is.
--
Stas Malyshev
smalyshev@gmail.com
Morning Stas,
I think we have to separate FRs and bugs. Bugs filed against older
versions (especially ones before 5.5) I'd put into feedback with request
to retest with more recent version. Feedback bugs would automatically
expire if no feedback was provided.
This sounds reasonable.
FRs however need more fine-grained approach. Since they are separate
from bugs, they are easy to filter out and in general may not be
version-specific. OTOH, having them there, indeed, is not super-useful,
but is not that harmful either.
The problem with accepting feature requests on bugsnet is that, most of the
time, nobody can implement them because of modern processes.
It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.
I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).
What do you think ?
We can still work through existing requests, but the chances of being able
to act on them are slim, and they are just going to sit there for years on
end.
Cheers
Joe
On Sun, Jan 8, 2017 at 9:57 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
I'd even go as far as saying that any bug reported for PHP < 5.6 can be
marked as "Won't fix". The bugs targeting 5.6 need to be checked whether
they have a security implication and if not they should be also marked
as "Won't fix"Lots of people run 5.5 now. I'd say at least about 2/3 of PHP users in
the field are now < 5.6. Blanket closing all those bugs with "wontfix"
sound non-productive to me - I'd rather at least give people chance to
update the info. Many extension bugs were transferred from 5.x to 7.x as
is.--
Stas Malyshev
smalyshev@gmail.com
Morning Joe
2017-01-09 7:13 GMT+01:00 Joe Watkins pthreads@pthreads.org:
The problem with accepting feature requests on bugsnet is that, most of the
time, nobody can implement them because of modern processes.It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).What do you think ?
We can still work through existing requests, but the chances of being able
to act on them are slim, and they are just going to sit there for years on
end.
For Feature Requests, I agree that we should disable them all together
on bugsweb, and add a page for redirecting the user to proper channels
like you mentioned.
Besides this, I would like some more statuses for the bug tracker, or
maybe rather auto reply/quick fixes instead of having to manually
copy/paste over and over again. An example could be:
"This extension ($ext) is no longer being actively maintained (Status:
Suspended)"
Also we got quick fixes for "Try a snapshot (5.4)" and even 5.5!
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Morning Kalle,
I would like some more statuses for the bug tracker
+1 go for it
Cleanup of code/statuses is also desirable ... and you have volunteered to
do it :D
Cheers
Joe
Morning Joe
2017-01-09 7:13 GMT+01:00 Joe Watkins pthreads@pthreads.org:
The problem with accepting feature requests on bugsnet is that, most of
the
time, nobody can implement them because of modern processes.It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.I think I would like to see feature requests disabled on bugsnet, thereby
pushing everyone to use the proper channels (github, internals, RFC's).What do you think ?
We can still work through existing requests, but the chances of being
able
to act on them are slim, and they are just going to sit there for years
on
end.For Feature Requests, I agree that we should disable them all together
on bugsweb, and add a page for redirecting the user to proper channels
like you mentioned.Besides this, I would like some more statuses for the bug tracker, or
maybe rather auto reply/quick fixes instead of having to manually
copy/paste over and over again. An example could be:"This extension ($ext) is no longer being actively maintained (Status:
Suspended)"Also we got quick fixes for "Try a snapshot (5.4)" and even 5.5!
--
regards,Kalle Sommer Nielsen
kalle@php.net
Hi!
The problem with accepting feature requests on bugsnet is that, most of
the time, nobody can implement them because of modern processes.
Why not? One can attach pull or write an RFC based on it. Having ticket
in bugs.php.net does not prevent it, it just records the need for it.
It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.
We can add comments to those FRs that require RFCs.
I think I would like to see feature requests disabled on bugsnet,
thereby pushing everyone to use the proper channels (github, internals,
RFC's).
These channels are not exclusive. In fact, bugs site is the only
permanent record for non-RFC requests, and for RFC ones, sometimes
significant time passes between idea showing up and RFC being ready, and
in that time, we won't have any record of anybody needing this.
What do you think ?
I don't think disabling FRs is good. Screening them and noting that some
of them will need RFCs to be implemented is good.
--
Stas Malyshev
smalyshev@gmail.com
Evening Stas,
(sorry for double delivery to you stas .... grrrrr)
A lot of the time a feature request is just not enough; it requires at
least a good discussion, if not an RFC.
When a PR is made on github, it interrupts everybody's day that has starred
or watched php-src: This has to be many more than have a subscription to,
or bother to read their subscription to bugsnet.
This usually results in a good discussion, at least it will draw out
objections and supporters more effectively than bugsnet does (because you
can just click an emoticon now) .
That there were feature requests open on bugsnet for more than a decade,
some without comments, some open as long as 15 years, should be a hint that
it is not useful as a collaboration tool anymore, and we have at our
disposal some of the best collaboration tools on offer for free.
All I really want to do at the moment is cleanup, but to be perfectly
honest I am not sure why we are using bugsnet for anything, given we took
the effort to switch over to git, source is hosted on github, the vast
majority of PECL extensions are hosted on github (or bitbucket or some
other collab+vcs solution), and they come with far superior collaboration
tools to the ones that nobody bothers to maintain for php-src.
I think this deserves consideration, we should be making the most out of
what is on offer.
I also think that doing things in the wide open has unseen benefits, while
bugsnet is open, it's in a dark corner of the internet that not enough
people bother to visit.
As mentioned, at the moment we should just clean up, but we should look to
the future, and we should move forward also ...
TL;DR I think we can do a better job of this if we use the right tools.
Cheers
Joe
On Mon, Jan 9, 2017 at 10:19 PM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Hi!
The problem with accepting feature requests on bugsnet is that, most of
the time, nobody can implement them because of modern processes.Why not? One can attach pull or write an RFC based on it. Having ticket
in bugs dot php dot net does not prevent it, it just records the need for
it.It's not harmful to us, but it is harmful to the person requesting the
feature, who is probably ignorant of modern processes, and bound to stay
that way until we educate them, or disable feature requests on bugsnet
altogether.We can add comments to those FRs that require RFCs.
I think I would like to see feature requests disabled on bugsnet,
thereby pushing everyone to use the proper channels (github, internals,
RFC's).These channels are not exclusive. In fact, bugs site is the only
permanent record for non-RFC requests, and for RFC ones, sometimes
significant time passes between idea showing up and RFC being ready, and
in that time, we won't have any record of anybody needing this.What do you think ?
I don't think disabling FRs is good. Screening them and noting that some
of them will need RFCs to be implemented is good.--
Stas Malyshev
smalyshev@gmail.com
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.
Thanks for bringing this up, Joe. Generally, I fully agree that we
should clean up the bug tracker ASAP.
I'm not sure, though, if doing a general mass cleanup would really be
the best thing. For instance, there are long-standing feature requests
which should already have been addressed, such as #32803 (I'm going to
start the RFC on this particular one soon) and #31784 (fontconfig is
already supported by external libgd, but not by our bundled one). Also,
there are long-standing bug reports such as #34670 which ideally would
have been resolved in the meantime, but haven't. Just wiping those
under the carpet wouldn't be an improvement, in my opinion.
Instead it would be great if we had active maintainers for all
extensions, and that these maintainers would concentrate on tickets
regarding their respective extensions (including relevant doc bugs).
PECL extensions which are not maintained anymore should be clearly
marked as such (on PECL and in the PHP manual), and all unresolved
issues could be marked as suspended. Unmaintained bundled extensions
should be considererd to be moved to PECL as soon as possible (there is
already a RFC draft[1] about this – I hope this will proceed soon).
Old tickets which can't be easily verified might best be handled by
asking whether the problem persists and setting the issue to "Feeback"
(such as #58167). That would still give users the possibility to
confirm that there's an unresolved problem, what appears to be
preferable to having a new follow-up ticket ("bug #12345 has been
closed, so I'm opening this ticket").
Also, we may consider building a triage team, similar to what had been
proposed for the pull requests[2], but never made it to a discission.
It seems to me that there a quite some developers who could assess a
certain issue, but might not be able to solve it by themselves with a
reasonable amount of effort. Those more proficient with the engine or
the respective extension could concentrate on bugs labeled "verified"
and "analyzed".
[1] https://wiki.php.net/rfc/umaintained_extensions
[2] https://wiki.php.net/rfc/github-pr
--
Christoph M. Becker
Morning Christoph,
Just wiping those under the carpet wouldn't be an improvement, in my
opinion.
Remember that the bugs won't go anywhere, they just won't present
themselves as important to new contributors, and old alike.
It's very overwhelming to see a list of five thousand things that may need
fixing, in reality most of the very old ones don't, and have no chance of
being addressed whatever.
If you're interested in looking through old FR's for stuff to RFC, then you
will still be able to do that.
We also have the option of adding a new status, such as "unresolved", so
that if you're so minded to go and look for old unresolved bugs, you can do
that with a simple search.
Leaving them open isn't helping anyone or anything, and if it overwhelms me
to see that many, you can be pretty sure it has scared a bunch of people
away.
Instead it would be great if we had active maintainers
Agreed, but we do not, and there isn't much we can do to change that.
The fact is that the burden lies with us to maintain anything in php-src,
not whoever put it there. There are few exceptions, Derick does an
excellent job of maintaining date, there are a few people who work hard to
try to keep PDO and other extensions in shape (or they are emerging now as
maintainers).
Unmaintained bundled extensions should be considererd to be moved to PECL
as soon as possible (there is already a RFC draft[1] about this – I hope
this will proceed soon).
I'm not sure what you mean by unmaintained, anything bundled is maintained
by virtue of the fact it is bundled ?
There's very few candidates for exclusion today. When I look at the list in
the RFC, it seems pretty obvious why some of them have no maintainer - the
underlying library is frozen in time (readline for example), there isn't
necessarily any real work to do, and nobody is obliged to satisfy
outstanding feature requests.
While I agree that some of those should be removed, I don't think it solves
any long term problems for us.
Old tickets which can't be easily verified might best be handled by asking
whether the problem persists and setting the issue to "Feedback" (such as
#58167).
This takes the kind of manual labour that we just can't do, and are failing
hard at doing already ... It really would take a team, and we don't have
one.
I know there are a few people that sporadically work on bugs, yourself
included, and that's great.
Maybe you could draft an RFC to put a team together, ask for volunteers to
work on that project and see what happens.
My proposed actions are not about sweeping anything under any carpets, they
are about:
- push people that have opened bugs with patches to go through github,
it's a more effective way of getting the job done - provide feedback to people that have been waiting for years on end for
some action - reduce the overall number of bugs so that new and old contributors are
not overwhelmed by the sheer number - make bugsnet a useful tool for finding things to fix in supported
versions of php - while it may seem that you can just search by version, in
reality this does not work, there are bugs that were opened for some old
version that still apply to 7
At some point, we need to admit that this is not manageable, and that
better tools exist for managing the influx of genuine bugs we do get. I
think actually we should consider closing down bugsnet entirely in the not
too distant future (maybe PHP8) and using the much better collaboration
tools provided by github.
Thanks for your valuable input, I look forward to seeing the bugs triage
RFC.
Cheers
Joe
On Sun, Jan 8, 2017 at 1:00 PM, Christoph M. Becker cmbecker69@gmx.de
wrote:
Some of you may have noticed that a few of us have put considerable
effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in
about
as long, they may concern defunct versions of PHP, or removed extensions
or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be
open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have
a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to
a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github
against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever
is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will
ever
have.Thanks for bringing this up, Joe. Generally, I fully agree that we
should clean up the bug tracker ASAP.I'm not sure, though, if doing a general mass cleanup would really be
the best thing. For instance, there are long-standing feature requests
which should already have been addressed, such as #32803 (I'm going to
start the RFC on this particular one soon) and #31784 (fontconfig is
already supported by external libgd, but not by our bundled one). Also,
there are long-standing bug reports such as #34670 which ideally would
have been resolved in the meantime, but haven't. Just wiping those
under the carpet wouldn't be an improvement, in my opinion.Instead it would be great if we had active maintainers for all
extensions, and that these maintainers would concentrate on tickets
regarding their respective extensions (including relevant doc bugs).
PECL extensions which are not maintained anymore should be clearly
marked as such (on PECL and in the PHP manual), and all unresolved
issues could be marked as suspended. Unmaintained bundled extensions
should be considererd to be moved to PECL as soon as possible (there is
already a RFC draft[1] about this – I hope this will proceed soon).Old tickets which can't be easily verified might best be handled by
asking whether the problem persists and setting the issue to "Feeback"
(such as #58167). That would still give users the possibility to
confirm that there's an unresolved problem, what appears to be
preferable to having a new follow-up ticket ("bug #12345 has been
closed, so I'm opening this ticket").Also, we may consider building a triage team, similar to what had been
proposed for the pull requests[2], but never made it to a discission.
It seems to me that there a quite some developers who could assess a
certain issue, but might not be able to solve it by themselves with a
reasonable amount of effort. Those more proficient with the engine or
the respective extension could concentrate on bugs labeled "verified"
and "analyzed".[1] https://wiki.php.net/rfc/umaintained_extensions
[2] https://wiki.php.net/rfc/github-pr--
Christoph M. Becker
Leaving them open isn't helping anyone or anything, and if it overwhelms me
to see that many, you can be pretty sure it has scared a bunch of people
away.
I have to agree. Since others already have expressed to be in favor of
a "mass cleanup", I'm not opposed. :-)
Unmaintained bundled extensions should be considererd to be moved to PECL
as soon as possible (there is already a RFC draft[1] about this – I hope
this will proceed soon).I'm not sure what you mean by unmaintained, anything bundled is maintained
by virtue of the fact it is bundled ?
It appears to me that several extensions get rather "odd fixes" only
(borrowing the terminology of EXTENSIONS).
While I agree that some of those should be removed, I don't think it solves
any long term problems for us.
I beg to differ. Fewer extensions mean less code to maintain.
Maybe you could draft an RFC to put a team together, ask for volunteers to
work on that project and see what happens.
I'll think about it. :-)
--
Christoph M. Becker
Hi!
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.
I would like to start with a big thanks to you for doing this. Long
overdue and finally happening!
With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.
I think we have to separate FRs and bugs. Bugs filed against older
versions (especially ones before 5.5) I'd put into feedback with request
to retest with more recent version. Feedback bugs would automatically
expire if no feedback was provided.
FRs however need more fine-grained approach. Since they are separate
from bugs, they are easy to filter out and in general may not be
version-specific. OTOH, having them there, indeed, is not super-useful,
but is not that harmful either.
I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.
True, some of the FRs actually need an RFC, so maybe we should note as
such on the FRs.
Stas Malyshev
smalyshev@gmail.com
Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.
Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
Perhaps something close to the Fedora bugs process could have some value.
-
1 month before a version goes EOL: add a comment "you reported this
bug against php xxx which goes EOL on .... It you are able to reproduce
with a newer version please update, else will be closed" -
after EOL: close the bugs as "wontfix"
Remi;
Morning Remi,
+1 on those criteria and ideas about commenting then closing ...
How long between commenting and closing do you think there should be ?
Kalle is going to get access to the bugsnet box, maybe he could get you
access (if you've time to get directly involved, I super hope you have) ?
Cheers
Joe
Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
Perhaps something close to the Fedora bugs process could have some value.
1 month before a version goes EOL: add a comment "you reported this
bug against php xxx which goes EOL on .... It you are able to reproduce
with a newer version please update, else will be closed"after EOL: close the bugs as "wontfix"
Remi;
Hi,
Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.
I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for feedback
if it's not clear how to try it.
Cheers
Jakub
Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
Hi,
Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.
Notice that my proposal includes a "feedback" step ;)
Le 09/01/2017 à 10:59, Jakub Zelenka a écrit :
Hi,
On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet remi@fedoraproject.org
wrote:Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
I disagree with this as many of bugs raised before 5.6 are still valid
bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also
introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.Notice that my proposal includes a "feedback" step ;)
Sure I noticed that. What I wanted to say is not just to automatically
close them if it's possible to try it (e.g. there is a piece of
reproducible code) and there is no feedback. Of course if it's not clear
how to recreate it and there is no feedback, then I agree it should be set
to "Won't fix".
Hi!
Sure I noticed that. What I wanted to say is not just to
automatically close them if it's possible to try it (e.g. there is a
piece of reproducible code) and there is no feedback. Of course if
it's not clear how to recreate it and there is no feedback, then I
agree it should be set to "Won't fix".
Won't fix is not a good status for a bug which is not reproducible or
incomplete.
Won't fix means that we know what's going on and we do not intend to
change it. If it's not clear what's going on, we should use status that
expresses it, such as "No feedback".
--
Stas Malyshev
smalyshev@gmail.com
Hi Jakub.
Am 09.01.17 um 10:59 schrieb Jakub Zelenka:
Hi,
Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
I disagree with this as many of bugs raised before 5.6 are still valid bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for feedback
if it's not clear how to try it.
I can understand that and from what I've seen so far during the cleaning
I can only say that you are right. A lot of the bugs reported for
versions before PHP 5.6 are still open. But going through all the 3000+
issues currently open agains PHP 5 is a LOT of effort. multiply that by
2 to also check whether they are still relevant.
As far as I see it there simply isn't the manpower to do that. We sadly
do not live in an ideal world but in Real Life(TM).
So giving the feedback that the issue was reported against an
unsupported version of PHP and asking the reporter to (re)open the issue
when it still is persistent in a supported version distributes that load
onto more shoulders.
And when it is obvious that the issue is still open, we can easily alter
the PHP-Version within the issue instead of closing it.
For the future an automated mechanism as described earlier would be
awesome. And that would spread the load back onto the reporter as well.
My 0.02€
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Hi Jakub.
Am 09.01.17 um 10:59 schrieb Jakub Zelenka:
Hi,
On Mon, Jan 9, 2017 at 7:25 AM, Remi Collet remi@fedoraproject.org
wrote:Hi,
Le 08/01/2017 à 07:46, Joe Watkins a écrit :
I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.Big +1 for a mass cleanup.
IMHO all bugs reported against PHP < 5.6 could be cleaned.
I disagree with this as many of bugs raised before 5.6 are still valid
bugs
. The reason is that the code for many extensions hasn't changed for long
time. Of course there was a port to 7.0 which fixed few and also
introduce
others but most of the old bugs are still valid. It would just hide
existing issues IMHO.I think that an ideal way would be to treat each bug individually and at
least try if the issue is still present before closing or ask for
feedback
if it's not clear how to try it.I can understand that and from what I've seen so far during the cleaning
I can only say that you are right. A lot of the bugs reported for
versions before PHP 5.6 are still open. But going through all the 3000+
issues currently open agains PHP 5 is a LOT of effort. multiply that by
2 to also check whether they are still relevant.As far as I see it there simply isn't the manpower to do that. We sadly
do not live in an ideal world but in Real Life(TM).So giving the feedback that the issue was reported against an
unsupported version of PHP and asking the reporter to (re)open the issue
when it still is persistent in a supported version distributes that load
onto more shoulders.
The disadvantage of this is that we can hide many of valid bug reports as
many users won't be just bothered to open it again (especially after 10
years). I don't see a big issues to have bugs open as they actually show
where the issues are and what part needs some work. I actually believe that
it's better to have a bigger backlog so one have got a bigger choice. Of
course cleaning up the bugs that are not really bugs or are already fixed
would be very helpful. However doing that automatically and closing also
the valid ones is not the best way how to do that IMHO.
Cheers
Jakub
Am 08.01.2017 um 07:46 schrieb Joe Watkins:
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.Cheers
Joe
+1 from me
i would help cleaning up but im not familiar with the bugsnet system :/
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in about
as long, they may concern defunct versions of PHP, or removed extensions or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will ever
have.Cheers
Joe
hi Joe,
thanks for triaging the github PRs, I also agree that we should do some
culling on our bugsweb issues (relevant: https://www.
joelonsoftware.com/2012/07/09/software-inventory/ ).
just wanted to mention that we have the feedback status, if a bug stays in
the feedback status for 2 weeks the bug will be closed by a cronjob with
the no feedback reason.
we could set the old bugs to feedback with an automatic comment that please
review the issue and target a supported version if you still want this
issue to be resolved and then let the reporters do that or the bug will be
closed.
I think this is a good compromise between just closing/suspending the
issues without explanation.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Morning Ferenc,
That was a good read, and echos my thoughts in places.
I never intended to do anything without explanation, that would obviously
have to be provided.
What I was hoping to extract from this conversation is some criteria for
the updating of bugs: What we actually consider old, what we consider won't
fix, and so on ...
Some good ideas have emerged, and I do hope the bug tracker does get the
attention it deserves in terms of functionality.
People with the power need to do something (that's you :)) to bring the
numbers down and focus our efforts, please do so, starting with updating
old bugs to feedback status.
Cheers
Joe
Morning internals,
Some of you may have noticed that a few of us have put considerable effort
into cleanup of pull requests on github, these are now manageable and I'm
quite confident that we will be able to merge pull requests in a timely
manner, and stay on top of it.When it comes to bugsnet, there are feature requests and bugs that have
been open for more than 10 years, and nobody has talked about them in
about
as long, they may concern defunct versions of PHP, or removed extensions
or
SAPIs: These numbers in the thousands.It's very difficult (impossible) to see a good reason for these to be
open,
they are not useful at all.With normal support for 5 ended, now is the perfect time to cleanup
bugsnet. If we can get the numbers down to something manageable, we have a
reasonable expectation to stay on top of them.I think anyone that has been waiting a number of years for a response to a
feature request deserves to know that it is not reasonably happening, and
that there are better ways of trying to get a feature in than opening
yet-another-feature-request on bugsnet.I think any bug report opened against 4 and not updated is useless.
I think anything with a patch attached targeting 5 is useless, regardless
of age; they should be encouraged to open a pull request on github against
a supported branch.I'd like to hear what others think about cleaning up bugsnet, what
criteria
we might use for a mass cleanup.After a mass cleanup, I/we will go in and start working through whatever
is
left, but 5k mostly irrelevant bugs is too much to ask, it would take me
months and months to work through those, time that nobody has, or will
ever
have.Cheers
Joehi Joe,
thanks for triaging the github PRs, I also agree that we should do some
culling on our bugsweb issues (relevant: https://www.joelons
oftware.com/2012/07/09/software-inventory/ ).
just wanted to mention that we have the feedback status, if a bug stays
in the feedback status for 2 weeks the bug will be closed by a cronjob with
the no feedback reason.
we could set the old bugs to feedback with an automatic comment that
please review the issue and target a supported version if you still want
this issue to be resolved and then let the reporters do that or the bug
will be closed.
I think this is a good compromise between just closing/suspending the
issues without explanation.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu