Patch Statuses in Launchpad (re-visited)

[Emmet Hikory]

Reinhard Tartler wrote:
> Moreover we need to make sure that such bugs have the assignee field set
> properly because of two reasons:
>  - bugs set to "Incomplete" are subject to expiration
>  - we need to make clear who needs to act next on the bug. In that case
>    we want the patch submitter to work on the patch, not the reporter.

    I don't want to limit the next person to touch the bug to the
patch submitter.  I've worked on a number of bugs where more than one
person works on the patch, a third (or fourth) person generates a
debdiff, and yet someone else uploads.

    I think there are three interesting cases where a patch might need
attention:

1) Where a patch is an incomplete or suboptimal solution, and could be improved
2) Where a patch can be tested by others to confirm the solution
3) Where a patch needs to be updated to match the current development
repositories
(I deliberately exclude those cases where there is additional workflow involved)

    In case #1, I'd hope that anyone with the requisite technical
skill and familiarity would submit a new patch for review.  In case
#2, I'd hope that a number of people would inspect the patch and
comment, and in case #3, I don't think the submitter should be
penalised for working on a supported release and that the update ought
be done by someone willing to work (and test) with the development
release.

Daniel Holbach wrote:
> I repeat: untagging the "patch flag" is easier, but we lose information
> that is very important if we don't want to lose possible solutions in
> the 40k bugs we have open anyway.

    Of these 40k bugs, only about 4000 have described solutions or
workarounds, and of these only about 2000 are in the form of a patch
that applies to some version of the source (which may not be the
current source).  While it is nice not to lose information, the patch
flag is not the appropriate means to indicate a bug has a known
solution (as many solutions are not sent as patches, and may not need
them), and for those people interested in reviewing patches, retaining
this does not help understand what patches need review.

    If the removal of the patch flag is used as an indicator that the
attached "patch" is not of any use, that has value in excess of the
value retained by remembering that someone attached a useless patch.
On the other hand, this is why I also advocate the use of the patch
tag in combination with the patch flag, such that those flagged, but
not tagged, are in need of review/improvement (and are not considered
useless), and those tagged are in need of review/upload.  While the
term "review" is common in both places, I suspect the nature of the
reviews to differ between determining whether a given attachment
provides part or all of a solution and whether a given patch is the
solution that belongs in the repositories.  Detailed meanings for
these states for specific bugs are likely best captured in bug
comments (which we ought be reading before taking action on a bug).

-- 
Emmet HIKORY