# Bugfest - Thread: https://externals.io/message/79964 - Original archive: https://news-web.php.net/php.internals/79964 - Started by Kalle Sommer Nielsen on 2014-12-27T15:01:56+00:00 - Messages: 35 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/79964.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 --- ## #79964 — Kalle Sommer Nielsen — 2014-12-27T15:01:56+00:00 URL: https://externals.io/message/79964#79964 Howdy dear Internals For a while I have been just stalking the bugs database[1], and I would love if we could some more focus on closing bugs. I'm not saying the job we do (my self included) is not being done well enough, but currently we have over 4.1k and a lot of those are old feature requests, or bugs going as far back as to PHP4. I do not have the technical experience on all subjects to close reports or analyze them as well for our many extensions but would love if we in the new year could have a similar event (maybe in user groups?) to analyze, test and lower that number. I know we all spend our free time to contribute to the project and we would rather spend time on making new features and fixing popular issues and a lot of our resources are shifted towards PHP7. Is there any momentum for lowering that number, I myself will try to resolve, close those I can, maybe we can close issues for extensions we no longer bundle or issues we had no response to for 1 year or 6 months+, if they are common issues we will surely get bumped about them. [1] http://bugs.php.net/ -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #79965 — Sebastian Bergmann — 2014-12-27T15:06:42+00:00 URL: https://externals.io/message/79964#79965 · In reply to: #79964 Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen: > bugs going as far back as to PHP4. Bug reports for PHP version that are not supported anymore [1] should IMHO be bulk-closed. The message should ask to reopen if the bug is reproducible with a supported version of PHP. IMHO :) -- [1] http://php.net/supported-versions.php --- ## #79966 — Rowan Collins — 2014-12-27T18:34:53+00:00 URL: https://externals.io/message/79964#79966 · In reply to: #79965 >Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen: > > […] > > Bug reports for PHP version that are not supported anymore [1] > should IMHO be bulk-closed. The message should ask to reopen if > the bug is reproducible with a supported version of PHP. IMHO :) The problem is that many will simply be labelled with whatever version was current at the time, and not updated, so this is equivalent to setting an age cut-off by date of filing, regardless of other activity. --- ## #79967 — Maciej Sobaczewski — 2014-12-27T19:04:17+00:00 URL: https://externals.io/message/79964#79967 · In reply to: #79964 Hello, yeah, I had very similiar idea (Symfony inspired me [1]). I also think that 4252 open bugs is quite too much and this number doesn't really reflect actual ammount of work to do. As you said, many bugs are critically outdated, some of them are probably duplicates and so on... I don't have many skills but I'll try to look at as many web/doc bugs, as I can, during this short holiday break. Cheers, Maciej. [1]: http://symfony.com/blog/the-symfony-500-100-challenge W dniu 2014-12-27 o 16:01, Kalle Sommer Nielsen pisze: > Howdy dear Internals > > For a while I have been just stalking the bugs database[1], and I > would love if we could some more focus on closing bugs. I'm not saying > the job we do (my self included) is not being done well enough, but > currently we have over 4.1k and a lot of those are old feature > requests, or bugs going as far back as to PHP4. > > I do not have the technical experience on all subjects to close > reports or analyze them as well for our many extensions but would love > if we in the new year could have a similar event (maybe in user > groups?) to analyze, test and lower that number. > > I know we all spend our free time to contribute to the project and we > would rather spend time on making new features and fixing popular > issues and a lot of our resources are shifted towards PHP7. > > Is there any momentum for lowering that number, I myself will try to > resolve, close those I can, maybe we can close issues for extensions > we no longer bundle or issues we had no response to for 1 year or 6 > months+, if they are common issues we will surely get bumped about > them. > > > > [1] http://bugs.php.net/ --- ## #79968 — Andrea Faulds — 2014-12-27T19:08:07+00:00 URL: https://externals.io/message/79964#79968 · In reply to: #79966 Hey all, > > > > > […] > > The problem is that many will simply be labelled with whatever version was current at the time, and not updated, so this is equivalent to setting an age cut-off by date of filing, regardless of other activity. As Rowan says, this would be a problem. Rather than just closing all bugs that are of a certain age, we should just go through all the open bugs one by one. 4000 open bugs is a lot, sure, but with a few people working at it I think we could get through that quite quickly. :) Thanks! -- Andrea Faulds http://ajf.me/ --- ## #79969 — Kalle Sommer Nielsen — 2014-12-27T19:35:57+00:00 URL: https://externals.io/message/79964#79969 · In reply to: #79968 Hi Andrea 2014-12-27 20:08 GMT+01:00 Andrea Faulds : > As Rowan says, this would be a problem. Rather than just closing all bugs that are of a certain age, we should just go through all the open bugs one by one. 4000 open bugs is a lot, sure, but with a few people working at it I think we could get through that quite quickly. :) I for one are against just closing old bugs without at least a review too. If we can have 5-10 developers (from any part of the community with a @php.net account) to look over a few bugs a day, then we can quickly bring that number down. We also have a fair bit of bugs assigned to people that I'm sure are not actively being worked on (notably Pierre, nothing personal here), but I doubt that Pierre have the time to work on the 120 bugs assigned to him at the moment, maybe some pieces, bits and bytes are laying around, I'm sure that also is a small factor for others, be that new contributors or veterans that will think that the bug is being worked on but really it isn't. Personally I have tried in December to lower my number and I'm down to below 10, whether that is simply unassigning myself, revewing the report or fixing it. Another thing with assignment of bugs is, some people are assigned by others because it is their area of expertise, take Dmitry for example he is one of the few guys that knows the Engine better than my own backpocket and often bugs are assigned to him for review but some ends up in the vast ocean of open bugs and are forgotten, again nothing personal and I have not been any better myself (I just closed an almost 4 year old bug assigned to me with a working patch). We could maybe have some advocates that could moderate bug reports and hand out some @php.net forwarder candy to such that wants to help the community but may not be able to write patches or fix them directly. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #79970 — Levi Morrison — 2014-12-28T01:05:23+00:00 URL: https://externals.io/message/79964#79970 · In reply to: #79969 > I for one are against just closing old bugs without at least a review > too. If we can have 5-10 developers (from any part of the community > with a @php.net account) to look over a few bugs a day, then we can > quickly bring that number down. I'll gladly enlist here. I've gone through bugs in the past but without others working it was tough to make a dent. As a general tip I recommend working on recent bugs: you are more likely to get feedback from the person who opened the bug. --- ## #79971 — Jacob Bednarz — 2014-12-28T01:48:49+00:00 URL: https://externals.io/message/79964#79971 · In reply to: #79970 One of the biggest issues I have found with the PHP bug tracker is the inability to filter on tickets and find the low hanging fruit based on a label or a priority. I realise the advanced search allows you to find based on package however this still is not enough. I am quite new to the development of the PHP internals so I am working my way through smaller tickets however it is quite cumbersome to paginate through all the listings in it's current state. I may be doing it wrong (and please let me know if I've missed something) however the workflow could definitely use some refining. If this functionality was available I think people would be more inclined to participate which would then free up the guys working on the lower level (and more in depth) issues within the engine. While this won't solve the issue of number of bugs reported, it may allow for a quicker resolution time. --- ## #79972 — Andrea Faulds — 2014-12-28T02:42:49+00:00 URL: https://externals.io/message/79964#79972 · In reply to: #79971 Hey Jacob, > > > One of the biggest issues I have found with the PHP bug tracker is the inability to filter on tickets and find the low hanging fruit based on a label or a priority. What do you mean by this? What’s a priority? You can sort by votes, you can filter by status, I’m not sure what you mean with “on a label”. Could you please elaborate? Thanks. -- Andrea Faulds http://ajf.me/ --- ## #79973 — Jacob Bednarz — 2014-12-28T03:09:04+00:00 URL: https://externals.io/message/79964#79973 · In reply to: #79972 > What do you mean by this? What’s a priority? You can sort by votes, you > can filter by status, I’m not sure what you mean with “on a label”. > > Could you please elaborate? Thanks. Sure - A label can be anything that is used to allow finer searching of issues. For example, I don't have a specific area of the PHP internals which I am concentrating on and instead would like to try a little of everything to see what I enjoy. If there was a label such as 'low hanging fruit' that could be searched upon and actioned by new comers. Instead, I need to go through all the packages and manually search for these entry level bugs. One other option might be adding a label which outlines the amount of effort required to complete the bug. I.e. easy, intermediate, hard. --- ## #79974 — Andrea Faulds — 2014-12-28T03:11:49+00:00 URL: https://externals.io/message/79964#79974 · In reply to: #79973 Hey Jacob, > > > > […] > > Sure - A label can be anything that is used to allow finer searching of issues. For example, I don't have a specific area of the PHP internals which I am concentrating on and instead would like to try a little of everything to see what I enjoy. If there was a label such as 'low hanging fruit' that could be searched upon and actioned by new comers. Instead, I need to go through all the packages and manually search for these entry level bugs. Well, there isn’t such a label because labels have to be created by people going through and adding that label to bugs. So someone has to look through 4000 bugs. > One other option might be adding a label which outlines the amount of effort required to complete the bug. I.e. easy, intermediate, hard. Same issue here. -- Andrea Faulds http://ajf.me/ --- ## #79975 — Jacob Bednarz — 2014-12-28T03:20:19+00:00 URL: https://externals.io/message/79964#79975 · In reply to: #79974 > Well, there isn’t such a label because labels have to be created by people going through and adding that label to bugs. So someone has to look through 4000 bugs. This definitely could be an issue for existing bugs but if it's available when someone creates a bug they could fill it out at that point. Also, the task itself of updating existing tickets with a level of effort required could be done by a new comer as the steps to reproduce and package should allow them to triage the issue and seek out any further information from the reporter better streamlining the investigation process. --- ## #79976 — Andrea Faulds — 2014-12-28T03:20:26+00:00 URL: https://externals.io/message/79964#79976 · In reply to: #79974 Hi again, > > > > […] > > Well, there isn’t such a label because labels have to be created by people going through and adding that label to bugs. So someone has to look through 4000 bugs. > > > […] > > Same issue here. I just want to follow up on what I just said, as I think I probably sounded quite dismissive. Those are good ideas and I think we probably should do them, but it’s not really a problem with the PHP bug tracker (tag support could be added if we needed it), rather that nobody’s gone and added such tags, I think. Perhaps we need a triage system like we sort-of have for pull requests. -- Andrea Faulds http://ajf.me/ --- ## #79978 — Remi Collet — 2014-12-28T06:45:20+00:00 URL: https://externals.io/message/79964#79978 · In reply to: #79965 Le 27/12/2014 16:06, Sebastian Bergmann a écrit : > Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen: > > […] > > Bug reports for PHP version that are not supported anymore [1] > should IMHO be bulk-closed. The message should ask to reopen if > the bug is reproducible with a supported version of PHP. IMHO :) I agree, we should close those old bugs. Ok, some of them can still exists. Perhaps we can imagine a process in 2 steps 1/ add a comment + feedback state This bug was created for a EOL version... Please reaffected if still occurs in more recent... Else will be closed in xx weeks 2/ close These steps can be repeat each time a version goes EOL for all bugs open against this version (ex step-1 a month before EOL, step-2 a month after) Remi. > -- [1] http://php.net/supported-versions.php --- ## #79979 — Maciej Sobaczewski — 2014-12-28T07:04:08+00:00 URL: https://externals.io/message/79964#79979 · In reply to: #79964 Hello guys, the work is going, number of open bugs slowly decreases. Meanwhile, I have sent a reminder[1] to all manual translations MLs, asking doc contributors for closing pending bugs. In best scenario, this should result in about next 40 bugs closed, as they are really easy to fix. One related thought. Perhaps someone with DB access, could delete all reports marked as Spam. I doubt they are removed automatically and I'm pretty sure there are bunch of them, cluttering database. Maciej. [1]: http://news.php.net/php.doc.de/4929 W dniu 2014-12-27 o 16:01, Kalle Sommer Nielsen pisze: > Howdy dear Internals > > For a while I have been just stalking the bugs database[1], and I > would love if we could some more focus on closing bugs. I'm not saying > the job we do (my self included) is not being done well enough, but > currently we have over 4.1k and a lot of those are old feature > requests, or bugs going as far back as to PHP4. > > I do not have the technical experience on all subjects to close > reports or analyze them as well for our many extensions but would love > if we in the new year could have a similar event (maybe in user > groups?) to analyze, test and lower that number. > > I know we all spend our free time to contribute to the project and we > would rather spend time on making new features and fixing popular > issues and a lot of our resources are shifted towards PHP7. > > Is there any momentum for lowering that number, I myself will try to > resolve, close those I can, maybe we can close issues for extensions > we no longer bundle or issues we had no response to for 1 year or 6 > months+, if they are common issues we will surely get bumped about > them. > > > > [1] http://bugs.php.net/ --- ## #79984 — Levi Morrison — 2014-12-28T18:35:30+00:00 URL: https://externals.io/message/79964#79984 · In reply to: #79978 I have committed a fix for one bug and closed another bug report because of this thread. I will continue to look at bugs but I wanted to spread some encouragement. --- ## #79985 — Paul Dragoonis — 2014-12-28T19:46:04+00:00 URL: https://externals.io/message/79964#79985 · In reply to: #79984 Come up with a way to incentivise people to fix bugs. My previous suggestion was to have a contributors page and it will rank people based on bug fixes. I'd be happy to work on this with someone. > I have committed a fix for one bug and closed another bug report > because of this thread. I will continue to look at bugs but I wanted > to spread some encouragement. --- ## #79986 — Christoph Becker — 2014-12-28T20:22:40+00:00 URL: https://externals.io/message/79964#79986 · In reply to: #79964 Kalle Sommer Nielsen wrote: > For a while I have been just stalking the bugs database[1], and I > would love if we could some more focus on closing bugs. Someone may consider reviewing the following bug reports :), which can be closed IMHO (see my respective comments): -- Christoph M. Becker --- ## #79987 — Kalle Sommer Nielsen — 2014-12-28T22:58:05+00:00 URL: https://externals.io/message/79964#79987 Hi Pasindu 2014-12-28 23:43 GMT+01:00 Pasindu De Silva : > Hi > I would like join and fix some I have been trying to fix some bugs in > DateTIme thought it was a good place to start, is there maybe a way to add a > label called > novice or starter bugs for people with little experience to get into. We do not have such functionality implemented in our bug tracker, usually you can say that Documentation/Translation bugs are rather easy to fix, vs. a bug in the scripting engine can be a much harder one to tackle. Depending on your skill level, if you are intermediate in C and a novice to the PHP/Zend API, then a good play to start looking for bugs and resolve them could be compilation, maybe you had to tweak the build system in a way to make it work or you are using a system for which a pending bug is open for[1] else the best all in all category that does not involve too many external APIs is the General issues which is a mix of all[2]. In the future please use reply-all, so that everyone on the list can read your message, if you got any more questions you are more than welcome to reply back to this thread. [1] https://bugs.php.net/search.php?cmd=display&bug_type=All&status=Open&package_name%5B%5D=%2ACompile+Issues&by=Any&limit=30 [2] https://bugs.php.net/search.php?cmd=display&package_name[]=%2AGeneral+Issues -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #79988 — Pasindu De Silva — 2014-12-28T23:01:38+00:00 URL: https://externals.io/message/79964#79988 · In reply to: #79987 Hi Kelle Thanks will dig in > Hi Pasindu > > 2014-12-28 23:43 GMT+01:00 Pasindu De Silva : > > […] > add a > > […] > > We do not have such functionality implemented in our bug tracker, > usually you can say that Documentation/Translation bugs are rather > easy to fix, vs. a bug in the scripting engine can be a much harder > one to tackle. > > Depending on your skill level, if you are intermediate in C and a > novice to the PHP/Zend API, then a good play to start looking for bugs > and resolve them could be compilation, maybe you had to tweak the > build system in a way to make it work or you are using a system for > which a pending bug is open for[1] else the best all in all category > that does not involve too many external APIs is the General issues > which is a mix of all[2]. > > In the future please use reply-all, so that everyone on the list can > read your message, if you got any more questions you are more than > welcome to reply back to this thread. > > [1] > https://bugs.php.net/search.php?cmd=display&bug_type=All&status=Open&package_name%5B%5D=%2ACompile+Issues&by=Any&limit=30 > [2] > https://bugs.php.net/search.php?cmd=display&package_name[]=%2AGeneral+Issues > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > -- *Pasindu De SilvaLinkedIn * *ppasindud@gmail.com* *G+ ppasindud * --- ## #79991 — Stanislav Malyshev — 2014-12-29T07:59:39+00:00 URL: https://externals.io/message/79964#79991 · In reply to: #79964 Hi! > For a while I have been just stalking the bugs database[1], and I > would love if we could some more focus on closing bugs. I'm not saying > the job we do (my self included) is not being done well enough, but > currently we have over 4.1k and a lot of those are old feature > requests, or bugs going as far back as to PHP4. We definitely need somebody triaging old bugs. The problem is it requires a real lot of time, and is mind-numbingly boring, so not many people do it. Many bugs are low quality - missing data, not having good descriptions, etc. - or > I do not have the technical experience on all subjects to close > reports or analyze them as well for our many extensions but would love > if we in the new year could have a similar event (maybe in user > groups?) to analyze, test and lower that number. Well, basic triage may be as simple as: 0) For all bugs that are older than 5.5 1) Look at the bug description. If the reproduction is not obvious from description, put it to "feedback" with request for better reproduction. If the submitter is no longer interested, it will be auto-closed as no-feedback with time. 2) Try to reproduce on 5.5/5.6. If it does not reproduce on either, close it with "not reproducible anymore, if you can reproduce on 5.6, please reopen". 3) If it reproduces on 5.6, put it in Verified status. This would not require anything but basic knowledge of PHP and lots of time. If somebody wants to do it, arguably millions of people would benefit from it - since it would make real bus more prominent, thus making PHP devs more likely to fix them, thus improving PHP which is used by millions :) - so it is a great way to contribute. Any takers? -- Stas Malyshev smalyshev@gmail.com --- ## #79996 — Levi Morrison — 2014-12-29T13:15:08+00:00 URL: https://externals.io/message/79964#79996 · In reply to: #79991 > > […] > > We definitely need somebody triaging old bugs. The problem is it > requires a real lot of time, and is mind-numbingly boring, so not many > people do it. Many bugs are low quality - missing data, not having good > descriptions, etc. - or > > > […] > > Well, basic triage may be as simple as: > 0) For all bugs that are older than 5.5 > 1) Look at the bug description. If the reproduction is not obvious from > description, put it to "feedback" with request for better reproduction. > If the submitter is no longer interested, it will be auto-closed as > no-feedback with time. > 2) Try to reproduce on 5.5/5.6. If it does not reproduce on either, > close it with "not reproducible anymore, if you can reproduce on 5.6, > please reopen". > 3) If it reproduces on 5.6, put it in Verified status. > > This would not require anything but basic knowledge of PHP and lots of > time. If somebody wants to do it, arguably millions of people would > benefit from it - since it would make real bus more prominent, thus > making PHP devs more likely to fix them, thus improving PHP which is > used by millions :) - so it is a great way to contribute. Any takers? ...and what to do with feature requests? --- ## #80009 — Stanislav Malyshev — 2014-12-29T18:02:54+00:00 URL: https://externals.io/message/79964#80009 · In reply to: #79996 Hi! > ...and what to do with feature requests? I would say - if it looks big (i.e. BC-breaking change, language change, completely new functionality that may influence other parts of the language, etc.), recommend submitting the RFC, otherwise if it's clear what is being asked than just leave them alone, if not then request feedback. -- Stas Malyshev smalyshev@gmail.com --- ## #80010 — Camilo Sperberg — 2014-12-29T18:18:33+00:00 URL: https://externals.io/message/79964#80010 · In reply to: #80009 I will have some time the next few days, I have little C knowledge and never committed something to PHP core, but I could take a look and do some cleanup. Sent from my iPhone 7 Beta [Confidential use only] > > > Hi! > > > […] > > I would say - if it looks big (i.e. BC-breaking change, language change, > completely new functionality that may influence other parts of the > language, etc.), recommend submitting the RFC, otherwise if it's clear > what is being asked than just leave them alone, if not then request > feedback. > -- > Stas Malyshev > smalyshev@gmail.com --- ## #80011 — Rafael Kassner — 2014-12-29T18:19:14+00:00 URL: https://externals.io/message/79964#80011 · In reply to: #80009 Any chance to people without Karma helping here? Maybe trying to reproduce the bug in 5.4+ and asking for feedback? Any workflow suggested? > Hi! > > > […] > > I would say - if it looks big (i.e. BC-breaking change, language change, > completely new functionality that may influence other parts of the > language, etc.), recommend submitting the RFC, otherwise if it's clear > what is being asked than just leave them alone, if not then request > feedback. > -- > Stas Malyshev > smalyshev@gmail.com --- Next page: https://externals.io/message/79964.md?page=2