Re: [OE-core] Bug reporting and good bug reports
On Wednesday 07 January 2015 16:36:37 Khem Raj wrote: On Jan 7, 2015, at 1:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. What about developer mailing lists ?. isn’t it also a way to report problems via emails after all we use emails for patch work flow. Not all people working with OE-Core e.g. might be following yocto bugzilla Mailing lists are great for discussion (e.g. I have this problem but I'm not sure of the right way to solve it) but a terrible way to track actual bugs, because mailing lists tend to concentrate on the latest postings; older issues that haven't been resolved rapidly disappear with the tide of new postings. Of course old issues can build up in a bug tracker, but at least it's trivially easy to find open issues where it's much more difficult to find unresolved issues on a mailing list. The point is, the best way to ensure that an issue gets solved at least for OE-Core is to file a bug in the YP bugzilla. There is then a triage process and in most cases someone to actually assign the issue to so that it can be dealt with. There is no such process on the mailing lists. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Jan 8, 2015, at 8:59 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: Assigning and scoping the actual work doesn't scale based on email threads (as someone who has been thrashing to keep information straight, and reproduce issues .. I feel this pain greatly). if you are a talking about corp development yes I agree for open source projects thats the nature of the beast. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Thu, Jan 8, 2015 at 12:29 PM, Khem Raj raj.k...@gmail.com wrote: On Jan 8, 2015, at 8:59 AM, Bruce Ashfield bruce.ashfi...@gmail.com wrote: Assigning and scoping the actual work doesn't scale based on email threads (as someone who has been thrashing to keep information straight, and reproduce issues .. I feel this pain greatly). if you are a talking about corp development yes I agree for open source projects thats the nature of the beast. I work with plenty of open source projects in my own time .. and if I have an issue, I open a bug if it requires a fix. Probably a point of view thing. We aren't saying that this is mandated .. just that anyone who can't be bothered to log a bug (and steps to reproduce it) .. should set their expectations for someone to fix it accordingly :) Bruce -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Jan 8, 2015, at 2:01 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 07 January 2015 16:36:37 Khem Raj wrote: On Jan 7, 2015, at 1:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. What about developer mailing lists ?. isn’t it also a way to report problems via emails after all we use emails for patch work flow. Not all people working with OE-Core e.g. might be following yocto bugzilla Mailing lists are great for discussion (e.g. I have this problem but I'm not sure of the right way to solve it) but a terrible way to track actual bugs, because mailing lists tend to concentrate on the latest postings; older issues that haven't been resolved rapidly disappear with the tide of new postings. Of course old issues can build up in a bug tracker, but at least it's trivially easy to find open issues where it's much more difficult to find unresolved issues on a mailing list. The point is, the best way to ensure that an issue gets solved at least for OE-Core is to file a bug in the YP bugzilla. There is then a triage process and in most cases someone to actually assign the issue to so that it can be dealt with. There is no such process on the mailing lists. for a user perspective when I try to google for any issue, first hits are not bugzilla, but the ml discussions I am just saying all different ways for reporting issues should be encouraged. Now if someone wants to turn it into a bugzilla entry thats good. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Thu, Jan 8, 2015 at 11:40 AM, Khem Raj raj.k...@gmail.com wrote: On Jan 8, 2015, at 2:01 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Wednesday 07 January 2015 16:36:37 Khem Raj wrote: On Jan 7, 2015, at 1:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. What about developer mailing lists ?. isn’t it also a way to report problems via emails after all we use emails for patch work flow. Not all people working with OE-Core e.g. might be following yocto bugzilla Mailing lists are great for discussion (e.g. I have this problem but I'm not sure of the right way to solve it) but a terrible way to track actual bugs, because mailing lists tend to concentrate on the latest postings; older issues that haven't been resolved rapidly disappear with the tide of new postings. Of course old issues can build up in a bug tracker, but at least it's trivially easy to find open issues where it's much more difficult to find unresolved issues on a mailing list. The point is, the best way to ensure that an issue gets solved at least for OE-Core is to file a bug in the YP bugzilla. There is then a triage process and in most cases someone to actually assign the issue to so that it can be dealt with. There is no such process on the mailing lists. for a user perspective when I try to google for any issue, first hits are not bugzilla, but the ml discussions I am just saying all different ways for reporting issues should be encouraged. Now if someone wants to turn it into a bugzilla entry thats good. For reporting an issue and discussing it, I don't disagree that something can happen on the mailing list. But if the reporter wants serious time spent on a bug (or I should say that the fix for the bug is something that will take more than a few minutes), I think it is reasonable to expect that the reporter (not the person working on the bug) takes the responsibility to get it into the bug tracker. Assigning and scoping the actual work doesn't scale based on email threads (as someone who has been thrashing to
[OE-core] Bug reporting and good bug reports
I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Bug reporting and good bug reports
On Jan 7, 2015, at 1:25 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: I was informed on irc yesterday that bug reports are hard and that debugging via irc is easier. I think I need to remind people why good bug reports are important and how they do actually help immensely. I do actually believe that not everything has to have bug report. If you mention an issue, someone says hey, I know how to fix that and sends a patch out, a bug report is wasted overhead IMO. I know some programme managers who disagree strongly with me and would suggest *every* bugfix commit should have a defect tracking item. We're not going there I understand the idea, its not practical. That said, if its not immediately clear what the problem is, it should become a bug report. Why? Firstly, the random selection of people on irc at the time probably aren't the right people to fix it. Telling those people to read 48 hours of irc log for the details is disrespectful of their time. It also happens that the first people referred to a bug may not be the person who actually can fix it. If someone else needs to come to a bug, having a summary of the issue, the salient facts and the current status is immensley useful for handover. As a case in point, I tried to debug a qt4 build failure yesterday for which there is no bug report. I lost hours building the wrong things, experimenting to try and find the reproducer steps and generally chasing my tail, losing the autobuilder log of the failure, the name of the qt4 recipe that was failing (which task was it again?) and so on. I do now have a set of reproducer steps, its quite simple: MACHINE=imx53qsb bitbake virtual/kernel MACHINE=imx53qsb bitbake virtual/kernel -c clean MACHINE=imx53qsb bitbake qt4-x11-free I also have a patch. Where should I share them? How do I ensure everyone with an interest in this defect actually gets the patch? Sure I can create email and send to the people who I think need to know. The bugzilla lets interested parties add themselves to bugs though. I should also note that QA actually go through bugs in the bugzilla, including closed ones, looking for test cases. We're not great at this yet but it does happen. If there is a well documented test case like that above, we might write an automated QA test for it. Having it documented is therefore a good thing. I do appreciate writing a bug report is hard, especially if you don't know where the problem is, or how to reproduce it exactly. It takes time and effort. You can however document what you know and discussion can happen in a common place to figure out how to reproduce it. I do except the submitters to fully understand the bug, if they did they'd probably write a patch instead. So fair warning, I am going to start ignoring things on irc and ask for bug numbers in future, assuming something isn't a 5 minute fix with an immediate patch. I will back and encourage anyone else doing this too. What about developer mailing lists ?. isn’t it also a way to report problems via emails after all we use emails for patch work flow. Not all people working with OE-Core e.g. might be following yocto bugzilla -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
