UDS-P: Community Bug Involvement

I drafted a blueprint at UDS-P this year to address the issue of poor bug reports and Ubuntu users being upset about ‘nothing being done’ about their bug reports. When I first drafted the blueprint I knew that many people in the Ubuntu Community did not understand that bug lifecycle and that the documentation was very complex.

Carlos De Avillez made a solid point during the discussion that changed my original perception and brought a solution in to focus.

Users are not trying to file a bug report; they are trying to solve a problem

That is an impactful statement! I had been focused on trying to teach people how to put in proper bug reports and to understand that SRCs do not happen that often. The focus now became on how to ensure that people just looking to get ‘stuff done’ using Ubuntu could find help without having to engage in filing bug reports that ended in frustration.

The first step in this will be to improve the pathway to resources that help resolve problems and only lead a person to filing a bug report as a last step. Also, making people aware that filing a bug report may not result in a fix until the next release of Ubuntu. Part of this will be to create a graphic flow chart of the process. On of the best flow charts I have seen is one from Fedora (seen below). I hope to make a chart that is similar, but that includes avenues for getting the problem solved prior to filing a bug.

I plan on starting to work on this diagram this weekend and will look for feedback from the community to ensure it is complete and easy to understand.

This entry was posted in Linux, Ubuntu. Bookmark the permalink.

3 Responses to UDS-P: Community Bug Involvement

  1. C de-Avillez says:

    Hi Charles — answering your question on #ubuntu-bugs:

    * a patch to a released version is always first proposed to the current Ubuntu development version (unless already contained in the current (development) package);
    * once accepted and verified on the development version, it is then proposed as a SRU (Stable Release Update) to the applicable Ubuntu version;
    * if the SRU request is accepted, then a package is built to -proposed; otherwise the process finishes;
    * the new (proposed) package is then tested;
    * if approved, it is then moved over to the corresponding -updates pocket; if not approved, the process restarts.

    Hope it helps,


  2. fuzzy says:

    Just wondering which tool did you use to create this draft picture? I am looking for such tool for very long time. The name of program would help me a lot. Thanks

    • Charles Profitt says:

      The image in this post is actually from Fedora and I did not make the image. I will be posting an image later that was made with Dia. You can also you yEd or LibreOffice Draw.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s