[oe] patch queue/patchwork: How should states be used? (was: update canutils to current version)

[Frans Meulenbroeks]

2010/8/13 Paul Menzel <paulepanter at users.sourceforge.net>:
> Am Freitag, den 13.08.2010, 23:01 +0200 schrieb Vitus Jensen:
>> On Fri, 13 Aug 2010, Khem Raj wrote:
>> > On Fri, Aug 13, 2010 at 2:59 AM, Vitus Jensen <vjensen at gmx.de> wrote:
>
> […]
>
>> >> They did.  But after you posted you ACKs I changed their state to "Accepted"
>> >> and then they are usually filtered by "Action Required".  I'm not really
>> >> sure I did the right thing but I don't believe they shouldn't remain in
>> >> "New".
>> >
>> > If they got applied change the state to 'applied'
>>
>> Sure, already did!  Do I set the 'archive' bit, too?
>
> I think so. Yes.
>
>> Frans got hit by the fact, that 'accepted' patches don't show up in the
>> list by default.
>>
>> Vitus posts patches
>> Frans acks patches
>> Vitus changes state to 'accepted'
>> Vitus asks Frans to apply
>> Frans: where are those patches in patchwork???
>> Frans forces his googlemail to produce usable mail and applies
>> Vitus changes state to 'applied'
>
> I would also advise to set the commit ID when setting the state to
> applied. Actually this can be done automatically [2], but the
> administrators have not yet had time to address this.
>
> We have the following 11 states.
>
>        $ pwclient state
>        ID    Name
>        --    ----
>        1     New
>        2     Under Review
>        3     Accepted
>        4     Rejected
>        5     RFC
>        6     Not Applicable
>        7     Changes Requested
>        8     Awaiting Upstream
>        9     Superseded
>        10    Deferred
>        11    Applied
>
> What is the difference between 3 (Accepted) and 8 (Awaiting Upstream)?

I'd say awaiting upstream would be a situation where the patch has
been submitted upstream (e.g. for gcc to the gcc devs) and we're
waiting for their reaction.
But that is just my guess.
>
>> Probably I should update the wiki [1] to document the above procedure, right?
>
> That would be great. But before there should be reached a little
> consensus to save you some unnecessary work.
>
> I guess the accepted state is too much work and could be skipped?
>
> + Normally people reviewing and acknowledging patches have commit access
> and will do this shortly afterward.
> - People with commit access not searching the list and just looking at
> the patch queue would see that those patches have been reviewed and
> acknowledged and could commit these patches.

Typically if I see something pass by that is straightforward (like the
patches from Vitus) and I have the time and my tree is in a state that
I can easily apply it, I take the patch and push it (after reviewing).
The rule I apply on myself is: if it is something that I woud push
myself without further review (e.g. a single recipe like the canbus
ones), I take it and push it and update patchwork. That is after
testing that the recipe builds.
so the workflow here is:

if it is a patch in an area I do not understand I'll skip it.
otherwise:

review patch. if ok and it is a simple patch
download patch from patchwork in mbox fmt
git am patch
bitbake recipe
if ok, git push.

if the patch is not ok, I inform the poster. I hardly ever repair things myself.
I'd rather educate people to do things the proper way.

And if the patch is complicated (e.g. affects the toolchain) I also
review and if possibly try then ack (or nak).

But sometimes I am not in a position to push (e..g because my system
or me is too busy with something else, or because my tree has too much
changes on it or is not up to date and cannot be updated)
In that case I tend to ack (and I might pick it up later) This is what
happened with vitus'  recipe.

>
> I do not know if we already have some people taking care of the patch
> queue. If there are such folks, they should voice their opinion what
> they prefer.

I feel taking in and handling patches is partly an orphaned process.
If a patch is submitted by someone with commit access for reveiw,
typically that person will follow up on it.
If it is e.g. a new recipe or in an area that is not really taken care
of by someone, it is sheer luck if someone picks it up.
I feel recipe maintainers could be useful here.

(btw recipe maintainers could also be useful when it comes to handling
bug reports in bugzilla).


Frans