# bugsnet cleanup - Thread: https://externals.io/message/97573 - Original archive: https://news-web.php.net/php.internals/97573 - Started by Joe Watkins on 2017-01-08T06:46:43+00:00 - Messages: 39 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/97573.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #97573 — Joe Watkins — 2017-01-08T06:46:43+00:00 URL: https://externals.io/message/97573#97573 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 --- ## #97574 — Maciej Sobaczewski — 2017-01-08T07:09:48+00:00 URL: https://externals.io/message/97573#97574 · In reply to: #97573 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. --- ## #97575 — Sebastian Bergmann — 2017-01-08T08:12:54+00:00 URL: https://externals.io/message/97573#97575 · In reply to: #97573 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 --- ## #97576 — Nikita Popov — 2017-01-08T10:29:40+00:00 URL: https://externals.io/message/97573#97576 · In reply to: #97573 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 --- ## #97578 — Joe Watkins — 2017-01-08T12:39:52+00:00 URL: https://externals.io/message/97573#97578 · In reply to: #97576 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 > 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 --- ## #97579 — Andreas Heigl — 2017-01-08T12:51:51+00:00 URL: https://externals.io/message/97573#97579 · In reply to: #97576 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 | +---------------------------------------------------------------------+ --- ## #97580 — Christoph M. Becker — 2017-01-08T13:00:11+00:00 URL: https://externals.io/message/97573#97580 · In reply to: #97573 > 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] [2] -- Christoph M. Becker --- ## #97581 — Joe Watkins — 2017-01-08T13:31:31+00:00 URL: https://externals.io/message/97573#97581 · In reply to: #97580 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 wrote: > > > > […] > effort > > […] > about > > […] > or > > […] > open, > > […] > a > > […] > a > > […] > against > > […] > criteria > > […] > is > > […] > ever > > […] > > 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] > [2] > > -- > Christoph M. Becker --- ## #97583 — Christoph M. Becker — 2017-01-08T14:07:16+00:00 URL: https://externals.io/message/97573#97583 · In reply to: #97581 > 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. :-) > > […] > > 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 --- ## #97597 — Stanislav Malyshev — 2017-01-08T21:54:04+00:00 URL: https://externals.io/message/97573#97597 · In reply to: #97573 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 --- ## #97598 — Stanislav Malyshev — 2017-01-08T21:57:08+00:00 URL: https://externals.io/message/97573#97598 · In reply to: #97579 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 --- ## #97611 — Joe Watkins — 2017-01-09T06:13:46+00:00 URL: https://externals.io/message/97573#97611 · In reply to: #97598 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 wrote: > Hi! > > > […] > > 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 --- ## #97613 — Kalle Sommer Nielsen — 2017-01-09T06:40:07+00:00 URL: https://externals.io/message/97573#97613 · In reply to: #97611 Morning Joe 2017-01-09 7:13 GMT+01:00 Joe Watkins : > 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 --- ## #97614 — Joe Watkins — 2017-01-09T07:14:15+00:00 URL: https://externals.io/message/97573#97614 · In reply to: #97613 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 : > > […] > the > > […] > able > > […] > on > > […] > > 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 --- ## #97615 — Remi Collet — 2017-01-09T07:25:38+00:00 URL: https://externals.io/message/97573#97615 · In reply to: #97573 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; --- ## #97616 — Joe Watkins — 2017-01-09T07:33:11+00:00 URL: https://externals.io/message/97573#97616 · In reply to: #97615 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 : > > > […] > criteria > > […] > > 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; --- ## #97617 — Jakub Zelenka — 2017-01-09T09:59:27+00:00 URL: https://externals.io/message/97573#97617 · In reply to: #97615 Hi, > Hi, > > Le 08/01/2017 à 07:46, Joe Watkins a écrit : > > > […] > criteria > > […] > > 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 --- ## #97618 — Remi Collet — 2017-01-09T10:04:33+00:00 URL: https://externals.io/message/97573#97618 · In reply to: #97617 Le 09/01/2017 à 10:59, Jakub Zelenka a écrit : > Hi, > > > > > […] > > > 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 ;) --- ## #97619 — Andreas Heigl — 2017-01-09T10:10:28+00:00 URL: https://externals.io/message/97573#97619 · In reply to: #97617 Hi Jakub. Am 09.01.17 um 10:59 schrieb Jakub Zelenka: > Hi, > > > > > […] > > > 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 | +---------------------------------------------------------------------+ --- ## #97621 — Jakub Zelenka — 2017-01-09T10:24:54+00:00 URL: https://externals.io/message/97573#97621 · In reply to: #97618 > Le 09/01/2017 à 10:59, Jakub Zelenka a écrit : > > […] > wrote: > > […] > bugs > > […] > introduce > > […] > > 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". --- ## #97622 — Jakub Zelenka — 2017-01-09T10:49:59+00:00 URL: https://externals.io/message/97573#97622 · In reply to: #97619 > Hi Jakub. > > Am 09.01.17 um 10:59 schrieb Jakub Zelenka: > > […] > wrote: > > […] > bugs > > […] > introduce > > […] > feedback > > […] > > 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 --- ## #97628 — Jan Altensen — 2017-01-09T16:10:38+00:00 URL: https://externals.io/message/97573#97628 · In reply to: #97573 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 :/ --- ## #97635 — Stanislav Malyshev — 2017-01-09T17:49:30+00:00 URL: https://externals.io/message/97573#97635 · In reply to: #97621 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 --- ## #97643 — Stanislav Malyshev — 2017-01-09T22:19:04+00:00 URL: https://externals.io/message/97573#97643 · In reply to: #97611 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 --- ## #97647 — Joe Watkins — 2017-01-09T22:54:54+00:00 URL: https://externals.io/message/97573#97647 · In reply to: #97643 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 wrote: > Hi! > > > […] > > 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. > > > […] > > We can add comments to those FRs that require RFCs. > > > […] > > 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. > > > […] > > 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 --- Next page: https://externals.io/message/97573.md?page=2