Canonical Voices

What Ubuntu Kernel Team Blog talks about

Posts tagged with 'triage'

Jeremy Foshee

Hi Folks,
It is that time again. Time for our regularly scheduled Bug Day [0]. Like last time we will be focusing on the bugs in the new state. We had a great amount of work done last time, and I’d like for us to keep that momentum going. There are a number of these bugs that have been improperly set to New when they should be either Triaged or Confirmed. My goal is for us to get as many of them properly set as possible. Additionally, we’d like to perform our basic triage on the ones that are, in fact, new. This includes a brief review of the information that has been provided and a request for what is missing so that we can get as many as possible into the triaged state for further review by the team.
I’d like to take a moment and thank those people on the team for working on the bugs with patches that we have. Through their efforts the number is the lowest it has been since I started here. There has also been quite a bit of effort put into continual review of the regression-proposed bugs. We now have them in a good place. All of this is due to the extra effort the team has put in, in addition to the massive amounts of work they normally do to achieve this. Thanks guys for your efforts. :-)

Parties interested in beginning triage or if you have questions about what to do, or if you just find yourself stuck on a bug and are not certain how to continue, please reach out to me in the #ubuntu-kernel channel on FreeNode. I’m always there, and I am always willing to help. :-)


Read more
Jeremy Foshee

As many of you have experienced this week, I have begun a (somewhat) aggressive review of old bugs for the Kernel package. In some cases bugs are being marked Invalid or Won’t Fix, and I am sure some of you will take issue with that. I’d like to explain some of the rationale behind these decisions and, hopefully, allay the majority of your fears concerning these issues.

First, I am not attempting to lessen the difficulty of any of these reported issues. I am marking the majority of the bugs Invalid due to the overwhelming responses of reporters having ‘similar’ issues. This has resulted in a watering down of the issue as reported by the Original Reporter. I do not wish to convey the notion that those of you encountering those issues are not important, quite the opposite. I am simply wishing to close an issue that is not really able to be solved and asking those of you experiencing issues of a similar nature in unique bugs of your own. This empowers me as a triager to drill down to individual causes of your issue and get that information in front of the team as opposed to trying to understand a variety of, possibly unrelated, issues from a multitude of reporters.

In some cases, you will see the Invalid status being applied to bugs that are very old. In these cases my preference is for affected users to, again, submit me a new bug with all of the relevant information. This gives me all of the benefits I have outlined above in addition to giving us brand new evidence of an issue in the current development release and will give the team a chance to take a fresh look at a longstanding issue.

There are also those bugs that have been Fix Released at some point in the past due to updates to a kernel. Well meaning reporters who experience a seemingly similar issue have, in the past, reopened these under an incorrect status and they have been lost in the shuffle of thousands of other issues. Let me say right now that it is not our policy to reopen Fixed bugs and I consider it a major no-no. :-) To those of you I fuss at for doing this, I apologize in advance.

Some of you will have seen bugs that are set to Won’t Fix. These are issues that are (once again, in most cases) being defined as hardware faults, BIOS issues or unrelated software configuration problems and cannot be fixed by changes in the kernel. In these cases, they are being marked Won’t Fix not our of a desire to keep from actually fixing an issue but in an effort to allow those invested in a product to take the opportunity to solve the problem in the correct location.

I speak from an experience around the team when I say that we would love to solve all of the issues presented to us. The reality is that we are able to take time on very few reported issues directly. The vast majority of fixes come through upstream commits or via new drivers provided by third parties.

To those of you who get annoyed when it seems that all I ever say on a bug is, “Is this still a problem in ” all I can do is shrug. Given the avenues open to us whereby a possible fix could come, I can only ask in that way. Please understand, I’d prefer there were some easier way. :-) Thanks for your patience as the team and I work to make this one of the easiest to use distributions while supporting the most hardware possible.

Finally, I’d like to say that, with such a broad install base and with such a large number of legacy devices available in the wild, there will be some cases where our answer to whether we will be able to support your specific device may end up being “No”. Please forgive me in those instances when I must be the bearer of bad news.

Thank you to all of you who help to triage bugs, update wiki pages and attend learning events put out by the Community team. With all of your help we can continue to improve our chosen operating system and make it more useful to those who would be free.


Read more
Jeremy Foshee

Hi everyone!

It is time once again to hold a Kernel Bug Day. I will start blogging these events now instead of only sending out the usual e-mail. I hope that some of you will join in.

This Tuesday, December 7th, the Kernel team will conduct a Bug Day focused on bugs tagged ‘regression-update’. These bugs are an indication that some update to the kernel caused a failure. We’d like for these bugs to be brought current by requesting testing on one of the other versions to include mainline and current development. Your help in requesting that information and in completing the general triage of these bugs would be greatly appreciated. :-)

Information concerning the Bug Day itself can be located on the wiki at As noted there and in the e-mail I sent out earlier, should you desire a head start on the triage day, that contribution too is most appreciated.

I will be available in the #ubuntu-kernel channel of the FreeNode IRC server should you have any questions.

Happy Triaging!


Read more
Jeremy Foshee

On Saturday September 11th the Kernel Team will take the first in what I hope to be a series of steps toward educating ourselves and our community in the triage of the thousands of bugs that pass our way daily.

My goal for this event is to begin the process of training those interested in helping with kernel bugs in the way we process our bug tickets. This first event is meant to help us both educate and document. The information on the first ever Triage Summit is located on the wiki here.

As with everything we do, your feedback is appreciated. Please don’t hesitate to send us e-mail to the team list at or even on the wiki page itself. Your feedback will go a long way toward our plans for future events like this.

The schedule for Saturday is as follows:

1) at 1400 UTC we will hold a General session centered around providing information as to where to locate us, who our upstreams are and where to find them as well as the new subsystem breakdown of bugs to help us gather related issues more easily and get them in front of the right people.

2) at 1500 UTC there will be a session on Graphics and all of its related bits and bytes. There will be a focus on basic, effective triage for this subset as well as locations to find troubleshooting information and further reading on Graphics issues

3) at 1600 UTC there will be a session on audio bugs and the related subsystem parts involved there. This session will also have a basic troubleshooting and location portion so as to guide those interested in triaging audio bugs with further information.

4) at 1700 UTC we will have something of a lightning round in which we briefly discuss the USB/Firewire and Bluetooth stacks as well as helpful debugging and triage steps for this subset of bugs

As stated before, your feedback on these sessions as well as the documentation that will be provided will be most helpful to us. You are also welcome to approach us for other avenues of support. We are always looking for more help on a variety of kernel related areas such as documentation, bugs and spelling/grammar applications :-) so please don’t hesitate to ask how you can help.

I look forward to seeing a great many of you at the Summit on Saturday!


Read more