Patch Statuses in Launchpad

[Scott Kitterman]

On Tue, 27 May 2008 13:07:31 +0900 "Emmet Hikory" <persia at ubuntu.com> wrote:
>Scott Kitterman wrote:
>> We need to stick with something very simple that is available in the U/I.
>>
>> If it's a patch, tag it.  If you review it and it needs more work, untag 
it an
>> comment.  That's simple enough we could actually do it.
>
>    This was the practice during the Gutsy cycle.  It was stopped in
>Hardy after some discussion as to whether the patch flag was enough,
>and what value the patch tag added.  Some package subscribers for whom
>there were several bugs with patches in the archives were also unhappy
>with the bugmail generated by adding the patch tag.

If there's a bug that makes this problematic, let's ask to have it changed.

>    Consider the following workflow:
>
>Case A:
>    Someone reviews bugs with the patch flag set.  Where there is a
>real patch, and it hasn't been rejected for some reason, the patch tag
>is set.  Where something isn't a real patch (screenshot, etc.), the
>patch flag is unset.

Sounds good.

>Case B:
>    Someone reviews bugs with the patch tag set.  Where the patch is
>good, tested, and working, they merge the patch into a candidate
>upload and push to the repository (setting the bug "In Progress"/"Fix
>Committed"/"Fix Released" as appropriate).  Where the patch is not
>acceptable for a variety of reasons, the patch tag is removed, and a
>comment is left in the bug explaining why the patch was rejected.

Sounds good. When a new/updated patch is included it is tagged patch and 
it's looked at again.

>Case C:
>    Combine Cases A and B to get the patch directly into the archive.
>
>    Note that bugs where patches are undergoing review may move
>regularly between the two lists, but until either a solution is found,
>or the patch is ultimately rejected as no longer meaningfully useful
>in any way, it makes sense to keep it in view.  Further, note that for
>the purposes of workflow, the input of patch authors is being ignored.

The reviewer workflow starts when there is something to review.  I'm a little confused what is 
needed.

> Anyone willing to work with patches ought be able to update them,
>create new candidates, etc. independent of these workflows.

I think they can if we keep it simple as I've suggested.

>    I don't see that much value in tracking whether a patch has been
>sent upstream.  If we have a bug, and we want to close it, we ought do
>so, rather than waiting for upstream.  It's good to send stuff
>upstream, and we ought do that, but I see it as separate from patch
>tracking within our bug tracker.
>
Agreed.

Scott K