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.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
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 :)
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 :)
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.
Hey all,
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 :)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/
Hi Andrea
2014-12-27 20:08 GMT+01:00 Andrea Faulds ajf@ajf.me:
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
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.
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.
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/
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.
Hey Jacob,
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.
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/
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.
Hi again,
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.
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.
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/
Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
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 :)
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.
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.
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.
Le 27/12/2014 16:06, Sebastian Bergmann a écrit :
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 :)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 weeks2/ 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.
--
this is what the feedback status does, 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(bugs targetting old php versions without any
activity for a while) to feedback and then let the reporters reply back or
the bug will be closed.
ps: I've just did a quick look, and we have bugs with feedback status which
are more than a year stuck in that status, I will look into what's wrong
with the cronjob which should closed these.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
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.
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 database1, 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.
Hello guys,
the work is going, number of open bugs slowly decreases. Meanwhile, I
have sent a reminder1 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.
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 database1, 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.
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):
https://bugs.php.net/bug.php?id=64600
https://bugs.php.net/bug.php?id=66703
--
Christoph M. Becker
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:
- For all bugs that are older than 5.5
- 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. - 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". - 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
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. - orI 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:
- For all bugs that are older than 5.5
- 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.- 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".- 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?
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
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!
...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
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!
...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
I'm pretty sure that just trying to reproduce a problem and posting
results in the comment, would be very helpful.
W dniu 2014-12-29 o 19:19, Rafael Kassner pisze:
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!
...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
My previous suggestion was to have a contributors page and it will rank
people based on bug fixes.
There appears to be a trend emerging where frameworks are making this more
of a feature on their sites and there's nothing people enjoy more than
getting recognition for their effort - even if it's just a place on a
ladder. Some examples:
- Symfony: http://symfony.com/contributors
- Ruby on Rails: http://contributors.rubyonrails.org
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
For someone new to the internals, this is a perfect place to start. While
the knowledge of the internals is quite limited, debugging and triaging
issues allows people to learn it in smaller and more managable chunks. I'm
hoping to contribute here to level up my knowledge so hopefully that makes
a positive impact - Even if it's "mind-numbingly boring" for starters. ;)
Well, basic triage may be as simple as:
- For all bugs that are older than 5.5
- 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.- 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".- If it reproduces on 5.6, put it in Verified status.
I quite like this approach as there is a large backlog of issues from
versions which have reached end of life and may have been fixed in newer
releases.
Levi wrote:
...and what to do with feature requests?
Stanislav Malyshev smalyshev@gmail.com wrote:
if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639
Leaving an issue like that open seems to pretty pointless, even though
it is clear what is being asked.
cheers
Dan
Levi wrote:
...and what to do with feature requests?
Stanislav Malyshev smalyshev@gmail.com wrote:
if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639Leaving an issue like that open seems to pretty pointless, even though
it is clear what is being asked.cheers
Dan
If you feel that it's unlikely that an FR will be implemented (e.g. for the
reasons you mentioned: a fringe use-case that's trivial to implement in
userland), close it. No point leaving FRs around that have no chance of
ever making it. If the OP insists that the functionality is important, you
can point him towards creating an RFC.
Nikita
Hi!
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639Leaving an issue like that open seems to pretty pointless, even though
it is clear what is being asked.
Yes, this one is pretty clearly not going to happen, but in general we
should tread lightly here - some ideas that seemed pointless in the past
ended up accepted and implemented. So if it's a clear-cut case, it's ok
to close but if there's any doubt, better to ask on internals or to let
somebody among experienced PHP devs take a look. Having a lot of open
feature reqs is ok, it's much less annoying that having a lot of open
bugs that nobody looks at.
--
Stas Malyshev
smalyshev@gmail.com
On 29 December 2014 at 07:59, Stanislav Malyshev smalyshev@gmail.com
wrote:
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. - orThis 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?
I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?
I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?
You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them it is useful if
you can reduce the size of reproduce code, verifiy it with current
versions, provide stack traces. By doing that you already save a lot of
time for developers.
If a name is seen with good comments a few times we give away accounts
which enable to close, assign, recategorize, ... bugs.
johannes
Hi Guys
What do you think about a folder "bugtests" with tests of all verified
bugs.
This can allows developers dive into the bug and test quickly I think and
also
devs fixing others bug might inadvertently fix other bugs.
I am currently trying to put together set of bug tests here
https://github.com/pasindud/php-bug-tests
let me know what you think.
+1
Pasindu
On Wed, Jan 14, 2015 at 10:38 PM, Johannes Schlüter johannes@schlueters.de
wrote:
I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them it is useful if
you can reduce the size of reproduce code, verifiy it with current
versions, provide stack traces. By doing that you already save a lot of
time for developers.If a name is seen with good comments a few times we give away accounts
which enable to close, assign, recategorize, ... bugs.johannes
--
--
Pasindu De SilvaLinkedIn http://www.linkedin.com/in/pasindud
ppasindud@gmail.com ppasindud@gmail.com
G+ ppasindud https://plus.google.com/u/0/107016732778776170349/
Hi
I been commenting on some bugs and putting some fixes also, dose anyone
know how to get edit access on bugs?
+1
On Thu, Jan 15, 2015 at 8:16 PM, Pasindu De Silva ppasindud@gmail.com
wrote:
Hi Guys
What do you think about a folder "bugtests" with tests of all verified
bugs.
This can allows developers dive into the bug and test quickly I think and
also
devs fixing others bug might inadvertently fix other bugs.
I am currently trying to put together set of bug tests here
https://github.com/pasindud/php-bug-tests
let me know what you think.+1
PasinduOn Wed, Jan 14, 2015 at 10:38 PM, Johannes Schlüter <
johannes@schlueters.de> wrote:I'd be willing to spend some time on this. Presumably I'd need some
authorised access to the bug tracker?You can simply add comments without special account, people with account
will follow up and close/assign accordingly. For them it is useful if
you can reduce the size of reproduce code, verifiy it with current
versions, provide stack traces. By doing that you already save a lot of
time for developers.If a name is seen with good comments a few times we give away accounts
which enable to close, assign, recategorize, ... bugs.johannes
--
--
Pasindu De SilvaLinkedIn http://www.linkedin.com/in/pasindud
ppasindud@gmail.com ppasindud@gmail.com
G+ ppasindud https://plus.google.com/u/0/107016732778776170349/
--
Pasindu De SilvaLinkedIn http://www.linkedin.com/in/pasindud
ppasindud@gmail.com ppasindud@gmail.com
G+ ppasindud https://plus.google.com/u/0/107016732778776170349/