Strawman: eliminating debdiffs

Daniel Holbach daniel.holbach at
Wed Oct 15 07:30:50 BST 2008

Hash: SHA1

Thierry Carrez schrieb:
> I think there are two levels of patching. One is to find the solution to
> the bug, and can be in proper diff format as well as carefully-worded
> suggestion. The other is a ready-to-be-sponsored debdiff. I suppose we
> want to encourage both, the first one to get solutions and testing from
> bug reporters without scaring them away, and the second one to train
> potential future developers to the subtleties of Debian packaging.

I agree. In the last time if small things like the changelog format
(etc.) was not perfect in the sponsoring bug, I simply changed it, added
a nice comment saying "this is what I changed and why I did it, thanks
for your great work". The replies almost always were "Oh thanks a lot,
I'll bear that in mind the next time."

This way we don't need to block on small issues, but still educate new

> In the best of worlds I would only use status field to track the status
> of the bug : we could use "Triaged" to mark that the bug has a solution
> (or that the developer already knows how to fix it), then have an
> additional "Fix proposed" status to track sponsoring:
> 1) patch is attached and turns up on "open bugs with patches" list
> 2) patch triage happens, use "Triaged" to show the bug has a solution
> 3) use "In progress" when working on a proper debdiff
> 4) use "Fix proposed" to get attention from the sponsors
> 5) Sponsors review and set back to "In progress" if not successful
> 6) Sponsors review and go to "Fix committed" when uploading
> 7) bug closed
> This would make the whole process more intuitive and easier to track,
> but would require more open access to the status field (and a new status
> to be available).

The problem with bug statuses is that there can be too much interpreted
into it. For instance "Fix Committed" to a lot of people means "there's
a fix available".

Actions which feel most natural to me are
 - set to "in progress" and assign to patch author to indicate "there's
work to be done"
 - subscribe/unsubscribe sponsors team to get input (I use for that)

What do we want to make sure has been checked already before a bug from
the "patch list" moves to the "sponsors list"? What do you think we
should add to the BugSquad documentation?

Have a nice day,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the ubuntu-devel mailing list