Ubuntu Bug Workflow and the Community

In the proprietary Apple or Microsoft environment bug reporting and work flow is, to me, more clearly defined to the end user. In most cases the manufacture of the software is responsible for bugs in its software and identifying the manufacturer is easy since their name is on the box the software came in or the website it was downloaded from. Despite this many end users still lack a basic understanding of this. The environment in Ubuntu does not have the same delineation since the software comes from Ubuntu’s software center. There is a warning about updates in the software center, but I think most end users do not fully understand how this applies to bugs.

Canonical does not provide updates for <software title>. Some updates may be provided by the Ubuntu community.

There is also a difference between a Canonical project and an upstream project that Canonical provides support for which adds even more complexity to the process over what exists for Microsoft and Apple. Microsoft only accepts public bug reports for twenty-one titles; a small fraction of the software they produce and sell. Ubuntu developers accept bug reports for a much larger set.

I believe the community needs to have a better understanding of this environment and the bug work flow and triage process. After giving this some thought three tiers of knowledge emerged.

  • Developers – high understanding of the entire process including the submission of patches to the repositories and upstream communication
  • Bug Triage / Bug Control – high understanding of the bug triage process including reporting the bug upstream, finding matching bug reports upstream and in other distributions
  • Ubuntu End User – general understanding of the bug triage process including knowledge about the existence of upstream bugs and a good understanding of how to report a bug

In recent cycles there has been a focus on improving bug-control and at UDS-P there are three blueprints regarding improving this process.

  • Process review and improvments for mentoring new Bug Squad members
  • bug tracking, targetting, lists
  • Detection of appropriate package for no package bug reports

These three sessions focus on the first two tiers. I have proposed a blueprint for inclusion at UDS-P for dealing with the third tier. I believe that if the third tier becomes more aware of the environment that initial bug reports will be better and the entire process will become much more efficient as a result.

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

3 Responses to Ubuntu Bug Workflow and the Community

  1. Pingback: Ubuntu Bug Workflow and the Community « Free Trader Beowulf | Linux Supersaniya

  2. Pingback: Ubuntu Bug Workflow and the Community « Free Trader Beowulf | effort.ly

  3. Pingback: Ubuntu Bug Workflow and the Community « Free Trader Beowulf | Linux Blog

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