It can be irritating filling bugs some times. Like when the bug reporter goes through the trouble of providing all the information needed and assigns it to where it should be assigned and then someone assigns it to something else and then asks what the bug was attached to. Instead of just reassigning bugs here there and everywhere the person that resigns the bug should be responsible for taking down any information they are changing like the original assignment.
I am guilty of not responding to questions on bugs but this is mostly through to this case of providing information which gets wiped and a month or two later having people ask you questions which you already provided the answers to, this is a big no no but it happens to 50% of the bugs I file.
Just thought I should say this here because its not always a case of someone being too lazy to respond. Filing bugs should be as quick and easy as possible and there shouldn't be a case where you have to come back and provide the same information again, its like going through a drive through and having them repetitively ask you your order because the machine is broken, its going to make you less likely to go back. :(

Yup, I've been doing this for the past couple of release cycles (both testing a livecd on hardware and lots more software testing in VBox). I haven't tested my hardware yet this cycle though, so thanks for the reminder.

On another note, I realize this might not be the best place to ask this, but do you know if there is any ongoing effort to fix webcam support in Jaunty? Intrepid broke a lot of hardware support for people's webcams. The latest versions of GSPCA kernel modules have fixed a lot of outstanding issues, but the fixes don't appear present in Jaunty, where things are still broken. This seems like kind of a big usability issue that was introduced with (ironically) BetterWebcamSupport from Fedora. It's frustrating for a user to have their webcam not work, and it's especially frustrating when the drivers are actually available. Is this something where we just have to wait for a newer kernel (and thus 9.10) or can these fixes be pulled into 9.04? Bug report here: https://bugs.launchpad.net/bugs/293259 and other related bugs.

Tretle:
I don't think the reporters are lazy. I think they're (rightly) afraid of running alpha versions. I'm trying to present ways to do it safely. The "Activity log" link in the upper right of a bug report will tell you what has changed, though I don't know how to fix the "unobservant triager" problem.

Jonathan:
Gensys Logic webcam support is coming, though I know the video support is slow (photo is much better). I can't get my other webcam at /dev/video1 to work though. Haven't determined if video1 v. video0 is the problem yet. Will have to test with other laptop.

Do you know if there's any way for me to help promote getting an updated version of GSPCA into Jaunty, which seems to fix a number of people's problems using a variety of webcams?

Jonathan:
Feature Freeze is in effect, but if you'd like to discuss fixing such regressions with the kernel team, please bring it up on the kernel-team mailing list.

On the other side of the coin, there's a LOT of "triagers" that only see triaging as a game of numbers, and will run through copious amounts of bugs pasting boilerplate about "have anything changed?" and then closing or otherwise changing the status to something that is guaranteed to not get it fixed. These people seem to a) think closed bugs means fixed bugs, and that the release gets better by having the number of open as low as possible in launchpad (false) and b) filling 5-a-day as soon as possible means you're doing a great job (also false).

If these people, instead of pasting useless questions that often clearly shows they haven't even read the actual report would try to test and reproduce a small number, or even one of these bugs themselves instead, they would do actual good instead of racking up their "high score". There was a developer just the other day on the planet saying much the same, though from the other point of view.

When I say that they aren't even reading the bug reports, I am not kidding. An example would be asking that kind of question about packages that has seen no change in version in Ubuntu nor Debian between versions. The odds that something else in the distro has changed so that the bug is fixed is are pretty low...

I want to try and help checking my own bugs, I really do. It's just not always feasible for a number of reasons, and the last thing I want to hear then is some drive-by "triager" that just closes my very valid bugs (usually with some rude boiler plate about how it's closed because noone cares) because that "triager" thinks it's all about racking up points.

A lot of it is about the attitude, really. It makes you stop filing every bug, because it's not handled seriously anyway. Ah well, at least it's better than trying to file *anything* in the Gimp bugzilla, where i suspect automated scripts close them with WONTFIX. ;)

I didn't check my RSS feeds til after I posted this, but I did see that post.

Yeah, that's a problem. Maybe we need to improve the wiki documentation? I'll go add a bit about using rmadison to check and see if the version has even changed since the bug was filed.

Stoffe:
Is this an improvement? Note that the __ things make that chunk of text be underlined.

Yes, definitely good improvements. :) I'm not sure about the hard line at 4 weeks at all, I would like to see another prod really, but i understand that there needs to be some process in place.

I think that the other thing that could be improved is the understanding of the purpose of this work (and with that, approach and attitude).

For instance, I like the idea of 5-a-day, but on the other hand it easily creates an environment where some people will try to get on the "high score tables", as such actually exists. Wanting to be there is not a bad thing in itself, but I think some people easily lose focus on what the purpose of doing this work at all is. An unfortunate and unwanted effect.

Perhaps that could be addressed as well somehow? Especially when talking about any points system such as 5-a-day (which wouldn't be so "bad" without the high scores) or launchpad karma or similar.

Yeah, I thought the line was 60 or 90 days. 4 weeks surprised me when I saw it on there. Looking at last June, it seems it has said 4 weeks for at least that long. It sounds pretty short to me though. I'd rather post a reminder comment at that point so the reporter gets an email reminding them that someone's waiting on them. I'm going to ask Brian Murray what he thinks about making reminder comments part of policy.

I try to do that, I often test live cds of alpha versions etc. and file bugreports or comment on them (in launchpad or on kde.org for example) but it's frustrating when nothing is happening. I'm willing to respond to questions but there aren't any pretty often. For example there is this bug that makes Ubuntu unusable for me on my netbook (https://bugs.launchpad.net/ubuntu/+bug/297263), but nothing has happened yet. :(

Stoffe:
more changes to Bugs/Responses

I'll send an email to the Ubuntu QA list. After 4 weeks, we'll send reminder emails. If no response within two weeks of the reminder, it can be closed.

Andreas:
Honestly, there are just plain a LOT of bugs, and we're not necessarily going to stumble around onto all of them. It doesn't really hurt to go into #ubuntu-bugs and ask if someone can take a look. Often real-time debugging in there can move things along much more quickly. And those lurking in the channel will learn more about what things to check. Everybody wins!

Okay, that's understandable, but it's still frustrating. ;)
I didn't know about that channel, so thanks, I will try it that way next time too! :)

An example of stoffe's point of people not reading bugs. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/315357

By the way, the 5-a-day charts are gone. At last UDS they talked about having the charts be "days in a row where 5+ bugs were touched" instead of letting people do 50+ on some days.

Tretle:
That says it was automated. I think it was sent out to all X bugs which lacked attachments. By the way, it's generally preferable for such things to be attachments so we don't have to scroll to Atlanta and back.

More good changes, thanks! That's the way I want it, too, with a reminder (or two, hehe).

The charts may be gone, but I saw this post on the planet today, with what I think is well-meant but sometimes encouraging suboptimal behavior: http://blog.qa.ubuntu.com/node/34

Specifically: "Wanna be famous? Is easy! remember to use 5-A-day so if you do a good
work your name could be listed at the top 5-A-Day Contributors in the
Ubuntu Hall of Fame page!"

The heart is in the right place, but pushing the "fame" button like that may have side-effects as per above. :)

meaning-less rant...

As a bug reporter, I wonder what I should do if i was told to retest the problem on a jaunty-alpha-liveCD, but the live cd could not boot(it got stuck on the screen where it asking if you want to install or other stuff). I don't want to burn multiple live cd's for each alpha; I only have so many cd-r's. I can't install the alpha since I _need_ the computer to function. if I report the problem with the live cd not booting I will be expected to test the next livecd-alpha; I will have to burn a lot of cd's. So I have not reported this bug since i know it will just be closed since i won't test the up-coming alpha's. I REALLY want to help test but I keep finding things making it harder on me. I don't want to burn a bunch of alpha-live cd's. Is there a way to boot from a cd-image that is on disk with out buring it? I tried to make start-up disk with my thumb-drive but my computer's BIOS can't boot usb-drives(arr i think there is a way around this with GRUB but I am still frustrated I can't test any thing).

How do you file bugs?

I'd be more active if I was being directed on an easy-to-follow/easy-to-implement bug reporting howto/system.

Thank you.

Mike - virtual box can boot a CD from the .iso file. No need to burn. However, there is no telling if your bug will still showup under virtualization. If it doesn't
you'll be able to test other stuff. :-)

All -
I am downloading the alternate alpha 5 for ADM as I write this. Sometimes I feel like there are so many bugs in Ubuntu it isn't worth looking for more. Most of what I find is already reported and when it isn't often I discover the problem is an issue with the way I've configured my system.

I'll give it another shot though. :-)

As far as 5-a-day goes: At one point my boss asked everyone to resolve
(not just touch) one bug a day and the result was a significant raise in
the bug submissions within 3 months. I think it is a mistake to reward lots of
work if you don't also reward work based on quality.

Ubuntu seems unable to handle the bugload they already have.

For example, I reported this: https://bugs.launchpad.net/ubuntu/+source/nautilus-actions/+bug/254171

in august 08. Then I re-tested and found it still present in the next ubuntu. Now I re-tested and it's still in Jaunty.

Indeed there's no indication that anyone has even glanced at it in the last 9 months. Yeah, sure, it's a trivial bug, but frankly, so should the fix be. (trivial, that is)

Testing, writing bug-reports, updating the bug when new releases are available, it's all rather pointless when it has no effect.

I've never had a bug in the kde-bug-tracker sit unchanged for even 3 months. I've pretty much given up reporting bugs to ubuntu. (I do report them upstream though, if they seem likely to be upstreams-bugs)

guptaxpn:
To report a bug, just get an account at Launchpad. Then go to the Ubuntu bug page. Tell it which package you found the bug in (if you can't figure it out, that's ok). Under the big text box it'll tell you some base iformation to include, such as what version of Ubuntu you found the bug in. Describe what you were doing when you found the bug, what happened, and what you expected to happen. Try to be very specific ("in __ menu, choose ___ option and then....") so it's easier to reproduce.

Eivind:
See what I said above. You're right, there are many more bugs than people to try to take care of them. I'm not actually sure about the bug you linked, since it might affect more than one part of the system.


I definitely encourage everyone here to try to help out with triaging when you've got some spare time. We can always use more help.

I'm extremely disappointed with treatment for bug reporting. I have four bug reports in my account, plus two or three that "affects me too", with absolutely no answer.

What's the point on going over and over about the need for providing more information, when this information is never checked once is provided? Let's not even mention the ridiculous absurd of the ubuntu-bug tool, making impossible for a non experienced user - which I though Ubuntu was aimed to be - to use.

I tried loading up Alpha 5 in virtualbox, but unfortunately I can not for the life of me figure out how to make it use a resolution higher than 800x600, and you can't even open Evolution at that size. Feel free to enlighten me... (Yes, I tried fiddling with the guest tools stuff.)

:( The Guest Tools stuff "should" work, but I'm actually a KVM user. I didn't want to recommend KVM because it really falls into the PITA category, though it does go for the largest 4:3 resolution it can fit (vertically) automatically.

If you want to try KVM for Ubuntu guests on Ubuntu hosts, python-vm-builder is probably the easiest way.

Also: Evolution doesn't work at 800x600? Ew! Bad! 800x600 is supposed to be GNOME's minimum resolution.

The easiest way to fix the screen resolution issue may be to install the guest additions. There is a button under devices that *should* mount a virtual CD/iso image containing the guest additions. Launch a terminal and then
cd /media/cdrom
sudo ./VBoxLinuxAdditions-x86.run
(Use the ADM version if you installed the AMD64 version of jaunty). You'll need to restart for the additions to take effect.

Once you have the additions installed you can resize the virtualbox window and the screen resolution of the VM should change with it. Cool!

SeanG:
I've never used RAID, sorry. That might be a question for http://www.freelinuxhelpline.net/ They have a weekly live show, and you can call in. The people running the show and those of us hanging out on IRC submit answers to the questions.