Launchpad bug retesting
Many bugs reported turn out to be hit and run reports where something is filed and never followed up. As such it is good that bugs are aggressively closed where possibly to prevent launchpad cluttering up. Unfortunately there are scenarios where this becomes problematic. These days I see people romping through launchpad asking for bugs to be retested on pre-releases of Ubuntu (which may be months away from their final release). These bugs are stuffed into a Incomplete state and then one month later closed (due to lack of response) before the final release of Ubuntu is ever released. Sometimes these are bugs with very thorough descriptions which are reproducible all the time so there is nothing stopping the launchpad gardener checking the problem. A flip side of this is that sometimes a bug is reported and again at some point before the next major release a request for testing is put out. The reporter goes away, tries the pre-release and tests the bug and reports back. Then another request to test another pre-release comes up because maybe it's been fixed but without any firm reason for this other than a minor point release change. Thus the bug is turned into a game of how many pre-releases the reporter can keep up with. The problem with all these requests for retesting is that the more bugs someone files the more retests they will be asked to do thus punishing those who file real bugs that are not resolved. In order to keep bugs.launchpad.net manageable perhaps collateral damage is inevitable but if you are expecting people to be repeatedly testing things every month (or see their bug closed) then it would be nice if this was stated up front. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Got Hardy? With Sound?
I've been unsuccessful in getting sound working, despite lots of tweaking. I've had the same problem with other recent distros using PulseAudio as well. I do note though, that the others include the PulseAudio controls by default where Hardy does not. They *are* in the archive though and I installed them, giving one access to the PulseAudio specific controls. However, just like with the other guys I still can't get sound working at all. In fact, right now about the only distro I *can* get sound working in is Knoppix 5.1 (but that's a year old). I wonder if this is a kernel issue? But I digress... -- Scott http://angrykeyboarder.com I've never used an OS I didn't (dis)like. I'm angrykeyboarder™ and I approved this message. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug retesting
On Thu, Mar 20, 2008 at 5:00 AM, Sitsofe Wheeler [EMAIL PROTECTED] wrote: Many bugs reported turn out to be hit and run reports where something is filed and never followed up. As such it is good that bugs are aggressively closed where possibly to prevent launchpad cluttering up. Unfortunately there are scenarios where this becomes problematic. These days I see people romping through launchpad asking for bugs to be retested on pre-releases of Ubuntu (which may be months away from their final release). These bugs are stuffed into a Incomplete state and then one month later closed (due to lack of response) before the final release of Ubuntu is ever released. Sometimes these are bugs with very thorough descriptions which are reproducible all the time so there is nothing stopping the launchpad gardener checking the problem. A flip side of this is that sometimes a bug is reported and again at some point before the next major release a request for testing is put out. The reporter goes away, tries the pre-release and tests the bug and reports back. Then another request to test another pre-release comes up because maybe it's been fixed but without any firm reason for this other than a minor point release change. Thus the bug is turned into a game of how many pre-releases the reporter can keep up with. The problem with all these requests for retesting is that the more bugs someone files the more retests they will be asked to do thus punishing those who file real bugs that are not resolved. In order to keep bugs.launchpad.net manageable perhaps collateral damage is inevitable but if you are expecting people to be repeatedly testing things every month (or see their bug closed) then it would be nice if this was stated up front. -- Sitsofe | http://sucs.org/~sits/ -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss Good morning, How would you suggest doing this instead? I am one of those that is combing launchpad for bugs that have not been reported or updated for a long time. I try to reproduce the bugs on my own system or vm which I try to run the development branch. If I am unable to reproduce it myself, I always ask the user to try and reproduce it as well. So how would you suggest dealing with those bugs instead of asking the end user to deal with it? Jonathan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug retesting
On 3/20/08, Jonathan Jesse [EMAIL PROTECTED] wrote: snip Good morning, How would you suggest doing this instead? I am one of those that is combing launchpad for bugs that have not been reported or updated for a long time. I try to reproduce the bugs on my own system or vm which I try to run the development branch. If I am unable to reproduce it myself, I always ask the user to try and reproduce it as well. So how would you suggest dealing with those bugs instead of asking the end user to deal with it? Jonathan They've already produced the bug if they've reported it. It is obviously important to ask if it is reproducible every time but the more critical information is determining _how_ to reproduce it. If you can't reproduce it on the version they're using, then obviously you can't assume it is fixed on the development release because you can't reproduce it there. Although, I imagine it would be safe to close the bug or ask for them to try and reproduce it if the version of Ubuntu that the bug occurred on is no longer supported and you can't reproduce the bug in a version that is supported. So, although you test, I don't think a lot of people do. Goals are important here. I don't think the goal should be to close as many bugs as possible. I believe the goal is to have as many bugs triaged _correctly_ so that they can be dealt with effectively. Thanks, Cody -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Launchpad bug retesting
Hi Cody, Cody A.W. Somerville wrote: On 3/20/08, Jonathan Jesse [EMAIL PROTECTED] wrote: snip Good morning, How would you suggest doing this instead? I am one of those that is combing launchpad for bugs that have not been reported or updated for a long time. I try to reproduce the bugs on my own system or vm which I try to run the development branch. If I am unable to reproduce it myself, I always ask the user to try and reproduce it as well. So how would you suggest dealing with those bugs instead of asking the end user to deal with it? Jonathan They've already produced the bug if they've reported it. It is obviously important to ask if it is reproducible every time but the more critical information is determining _how_ to reproduce it. If you can't reproduce it on the version they're using, then obviously you can't assume it is fixed on the development release because you can't reproduce it there. Although, I imagine it would be safe to close the bug or ask for them to try and reproduce it if the version of Ubuntu that the bug occurred on is no longer supported and you can't reproduce the bug in a version that is supported. So, although you test, I don't think a lot of people do. Goals are important here. I don't think the goal should be to close as many bugs as possible. I believe the goal is to have as many bugs triaged _correctly_ so that they can be dealt with effectively. Well sounds good...but where are the people who are doing the bugfixes? we can test, reproduce etc. Having for every bug a patch handy and an SRU is a lot of paperwork, and those uploads to -proposed won't even show up in -updates, when there is no one who is testing. So, especially for the voluntary part of Ubuntu, it's quite important for the guy/gal who is working on the package, if the bug still exists in the latest devel release...so he/she can decide to actually work on an SRU or to just go on or to fix it in latest devel release. The problem here is, as it's always, human-power :) \sh -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Got Hardy? With Sound?
Hi, Am Thursday 20 März 2008 13:33:50 schrieb Scott (angrykeyboarder): I've been unsuccessful in getting sound working, despite lots of tweaking. I've had the same problem with other recent distros using PulseAudio as well. [..] In fact, right now about the only distro I *can* get sound working in is Knoppix 5.1 (but that's a year old). I wonder if this is a kernel issue? did you try sound with anything else but pulseaudio (e.g. running speaker-test to check alsa?) Also, please report bugs to launchpad, thanks! Cheers, Stefan. signature.asc Description: This is a digitally signed message part. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
