Strawman: eliminating debdiffs

[Thierry Carrez]

Daniel Holbach wrote:

> The part in our process that involves subscribing ubuntu-*-sponsors
> basically means "somebody who can upload the patch, please review it". I
> agree with what Colin said in his mails earlier that this review should
> be more about the solution of the problem than the formatting of the
> changelog or other subtleties.
> [...]
> Our workflow for getting some kind of patch integrated into Ubuntu is
> somewhat limited by Launchpad Bugs not offering information about the
> status of a patch. Maybe the solution is to have some kind of "patch
> triage" and a guide for how to do it. Items that come to my mind are:
>  - *is* it a patch (and not a screenshot)?
>  - does it apply against the current development version?
>  - where is the patch from?
>  - was it accepted upstream already?
>  - is it properly documented?
>  - etc.
> 
> If somebody is willing to tidy up the patch, bring it into debdiff
> format, add a nice changelog entry, etc during this "patch triage" even
> better. Once this has been done, it would make sense to have some
> ubuntu-dev member review it, test it, and if it's all good upload it.

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.

> To try to workaround the limitations in Launchpad Bugs and add
> information to classify those 2006 bugs in terms of "what needs doing
> now?" we could try the following:
>  1) patch is attached and turns up on "open bugs with patches" list
>  2) patch triage happens, tag "triaged-patch" added
>  3) ubuntu-*-sponsors is subscribed, review happens
>  4) patch needs work, ubuntu-*-sponsors is unsubscribed
>  5) ubuntu-*-sponsors re-subscribed, review is good, uploaded
>  6) bug closed

I'm not a big fan of using tagging and subscriptions to track bug
resolution status, as it makes the process rather opaque to newcomers,
but I agree that Launchpad has limitations that we need to workaround.

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).

-- 
Thierry Carrez
Ubuntu server team