The Definition of Fix Committed

[Greg Grossmeier]

Hello all,

I have recently started some conversations in both #ubuntu-bugs and 
#ubuntu-qa regarding what the use case is for Fix Committed.  The reason 
I brought up the topic is because of one specific issue: the difference 
in what the bug status wiki page says [0] and what some people/teams do.

Quoting from the status wiki page for Fix Committed:
-----
1) For a bug task about an upstream project: the fix is in CVS/SVN/bzr 
or committed to some place

2) For an Ubuntu package: the changes are pending and to be uploaded 
soon (it's what PENDINGUPLOAD was in Bugzilla)

3) Fix Committed is also used when an updated package exists in a 
-proposed repository i.e. hardy-proposed

4) Fix Committed is not to be used when a patch is attached to a bug
-----

Case 1 refers to the bug task for the upstream project, ie: a link to 
the bug report in GNOME's bugzilla.  However, you would only manually 
set this to Fix Committed when there is no bug in the upstream 
bugtracker yet you know that a fix was indeed committed to the project's 
revision control.  Otherwise the status is automatically updated based 
on the upstream bug's status.

Cases 2-4 refer to the Ubuntu task (usually says "$packagename 
(Ubuntu)").  None of these refer to the case a fix was merely committed 
to any revision control.  The normal use if when a package is in 
-proposed for testing purposes.  You could think of the fix as Committed 
to Ubuntu but not Released to all users yet.

However, the confusion comes when a fix is indeed committed in 
upstream's revision control and to signify this some people/teams set 
the Ubuntu task to Fix Committed.  This use case is not stated on the 
wiki page.  The reason this is done is so when viewing a package's bug 
list triagers can easily see which bugs are fixed upstream[1].  This is 
most commonly done by the Ubuntu Desktop Team due to the large number of 
bugs which they are responsible for.


My commentary: I believe that the use of Fix Committed in the Ubuntu 
task for when upstream has committed a patch is a workaround for a real 
problem.  This problem should be fixed directly, not hacked around.

To fix this problem the bug list for a package could include a column or 
some graphical indicator that an upstream task is marked as Fix 
Committed/Released.  To keep some of the cleanness of Launchpad this may 
be a separate bug list instead of complicating the normal bug list.

Side-issue: The use of the Fix Committed status is of debatable 
effectiveness.  I know there have been discussion of reducing the number 
of status options to reduce confusion like this.  I'm not sure that 
would help the situation or make it worse; opinions which account for 
all use cases are more than welcomed.


My proposal: Unify the use of Fix Committed across all teams in Ubuntu 
(with the exception of work-flow/archive inclusion reports).  This could 
be done by either using Fix Committed as the wiki page says [0] or as 
some teams/individuals do.

My preference is to do as the wiki and then actually fix the issue with 
a modification to Launchpad to show bugs which have a Fixed upstream task.

Do you have opinions/comments/questions on this?

Best,

Greg


[0] https://wiki.ubuntu.com/Bugs/Status
[1] https://bugs.edge.launchpad.net/ubuntu/+source/poppler