patchwork cleanup call

patchwork cleanup call

[Khem Raj]

Hello OE'ers

We have accumulated quite a bit of mails in patchwork. Patches that
are send to OE ml are nicely captured by
patchwork and shown when one visits http://patchwork.openembedded.org

It would be nice if committers,reviewers and authors update the patch
status when they deal with the patch

So please spare few minutes and have a look at the patchlist and see
if there is a patch authored or committed by you and update the status
accordingly.

I regularly use this tool to pick up patches and this exercise will
help to remove the stale patch states

Thanks for your time

-Khem

Re: patchwork cleanup call

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 21-10-10 22:58, Khem Raj wrote:
> Hello OE'ers
> 
> We have accumulated quite a bit of mails in patchwork. Patches that
> are send to OE ml are nicely captured by
> patchwork and shown when one visits http://patchwork.openembedded.org
> 
> It would be nice if committers,reviewers and authors update the patch
> status when they deal with the patch
> 
> So please spare few minutes and have a look at the patchlist and see
> if there is a patch authored or committed by you and update the status
> accordingly.
> 
> I regularly use this tool to pick up patches and this exercise will
> help to remove the stale patch states

We can do as we did in the past and say "On the first of november we're
archiving all patches older than october 2010" to give people a bit more
incentive.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMwTLaMkyGM64RGpERAkkjAKCRvMcv5esVP1e7hHyT06eQUbqMugCgo9SG
MMYE0QshOMpsXRsv99oQnAI=
=5c50
-----END PGP SIGNATURE-----

Re: patchwork cleanup call

[Martin Jansa]

On Fri, Oct 22, 2010 at 08:44:42AM +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 21-10-10 22:58, Khem Raj wrote:
> > Hello OE'ers
> > 
> > We have accumulated quite a bit of mails in patchwork. Patches that
> > are send to OE ml are nicely captured by
> > patchwork and shown when one visits http://patchwork.openembedded.org
> > 
> > It would be nice if committers,reviewers and authors update the patch
> > status when they deal with the patch
> > 
> > So please spare few minutes and have a look at the patchlist and see
> > if there is a patch authored or committed by you and update the status
> > accordingly.
> > 
> > I regularly use this tool to pick up patches and this exercise will
> > help to remove the stale patch states
> 
> We can do as we did in the past and say "On the first of november we're
> archiving all patches older than october 2010" to give people a bit more
> incentive.

Would be nice to have spam feature in patchwork.

Just sending state query to every Submitter email for patches in some
state (in this case not archived, "Action Required"), with link to it's
patchwork entry.

Maybe someone with better patchwork knowledge or pwclient can get the
list of Submitters easier than parsing html?

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: patchwork cleanup call

[Frans Meulenbroeks]

2010/10/22 Martin Jansa <martin.jansa@gmail.com>:
> On Fri, Oct 22, 2010 at 08:44:42AM +0200, Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 21-10-10 22:58, Khem Raj wrote:
>> > Hello OE'ers
>> >
>> > We have accumulated quite a bit of mails in patchwork. Patches that
>> > are send to OE ml are nicely captured by
>> > patchwork and shown when one visits http://patchwork.openembedded.org
>> >
>> > It would be nice if committers,reviewers and authors update the patch
>> > status when they deal with the patch
>> >
>> > So please spare few minutes and have a look at the patchlist and see
>> > if there is a patch authored or committed by you and update the status
>> > accordingly.
>> >
>> > I regularly use this tool to pick up patches and this exercise will
>> > help to remove the stale patch states
>>
>> We can do as we did in the past and say "On the first of november we're
>> archiving all patches older than october 2010" to give people a bit more
>> incentive.
>
> Would be nice to have spam feature in patchwork.
>
> Just sending state query to every Submitter email for patches in some
> state (in this case not archived, "Action Required"), with link to it's
> patchwork entry.
>
> Maybe someone with better patchwork knowledge or pwclient can get the
> list of Submitters easier than parsing html?
>
> Regards,

Nice ideas, but....

As far as I see it there are two often occurring situations:

- a patch is submitted for review and gets zero feedback. I have quite
a few of these in patchwork. I once proposed that if a patch does not
get neg feedback in two weeks or so it could be pushed anyway. While
this got some positive response it was never really made a policy. But
I must say I'm becoming more and more inclined to push them anyway.

- a patch is submitted by someone without commit access but no one
picks up the patch.

In either case if patches just get archived without being looked at,
it'll probably have an adverse effects.
The person without commit access will probably stop submitting
patches, since they do not get accepted.
And a dev with commit access will stop to send in patches for review
as they will not get reviewed anyway, and only causes delay, and
instead push the patches directly.

Wrt the suggested solutions:

archiving the patches is just a way to discard them. No one is ever
going to pick them up from the archive. It'll probably lead to less
patches and disappointed submitters.

spamming might help in the case where the submitter has commit access
and we decide that no feedback during some time is an implicit
permission to push.
However in the case the submitter has no commit access it will only
cause additional grief as the submitter becomes more aware that no one
bothered to do anything with his patch.


What would help a little bit is if there is an email on a status
change. E.g. I just noticed someone assigned two patches to me.
However, if I hadn't looked into patchwork while typing this message
it could have easily taken a week before I had noticed (actually it is
quite possible that they are already a week on my name).

What also would help is identified recipe maintainers. That way it
becomes clearer who should handle a patch.
(and I probably would not have gotten those 2 patches, as they are on
python related stuff and I am a python n00b, guess they should have
gone to Mickey or so)

And lastly it would help a little bit if it is stated somewhere if the
person who pushed it has commit access.
E.g. if someone without commit access posts a recipe or patch that
looks good and is not dangerous I sometimes pick it up and push them
after verifying that they build (e.g. the cd/dvd recipes from Andreas
Oberritter (sp?) ). If the person posting has commit access, I leave
it to them to push.

But we of course still have the problems that
- people nak recipes but do not update patchwork
- patches receive improvement suggestions and are not updated in patchwork
- new versions are posted but patchwork is not updated.

Guess we could discuss this at OEDEM.
Also I would not mind to have a session at OEDEM (fri evening?) where
we go through the list and decide per patch what to do with it, or
whom to assign it to.

Best regards, Frans

Re: patchwork cleanup call

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22-10-10 09:32, Frans Meulenbroeks wrote:

> As far as I see it there are two often occurring situations:
> 
> - a patch is submitted for review and gets zero feedback. I have quite
> a few of these in patchwork. I once proposed that if a patch does not
> get neg feedback in two weeks or so it could be pushed anyway. While
> this got some positive response it was never really made a policy. But
> I must say I'm becoming more and more inclined to push them anyway.
> 
> - a patch is submitted by someone without commit access but no one
> picks up the patch.

What I do is ping patches that get zero feedback, people sending patches
should do the same.

And when I'm travelling I can't post to the ml, so every month there's a
working week were I can't give feedback and with my goldfish memory I
forget it the week after.

And if you're going to push an 'old' unreviewed patch, it's easy enough
to ack it on the ml and wait a bit to see if someone suddenly spots a
huge bug in the patch.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMwUmRMkyGM64RGpERAh7mAJ9ZyDnQo45N01fLgaC87u8umFaxfgCdEmr0
UciwwVyzo9CnkokxRpuehxk=
=mbDk
-----END PGP SIGNATURE-----

Re: patchwork cleanup call

[Martin Jansa]

On Fri, Oct 22, 2010 at 09:32:19AM +0200, Frans Meulenbroeks wrote:
> Nice ideas, but....
> 
> As far as I see it there are two often occurring situations:
> 
> - a patch is submitted for review and gets zero feedback. I have quite
> a few of these in patchwork. I once proposed that if a patch does not
> get neg feedback in two weeks or so it could be pushed anyway. While
> this got some positive response it was never really made a policy. But
> I must say I'm becoming more and more inclined to push them anyway.

Maybe it's not written as policy but as koen said, send ping and if
still no reply then probably nobody cares it being pushed (so you can
push it).

> - a patch is submitted by someone without commit access but no one
> picks up the patch.

ping stating that author has not commit access would be nice

> In either case if patches just get archived without being looked at,
> it'll probably have an adverse effects.

Agreed

> But we of course still have the problems that
> - people nak recipes but do not update patchwork
> - patches receive improvement suggestions and are not updated in patchwork
> - new versions are posted but patchwork is not updated.

All 3 cases seems like author fault, sometimes I've contacted author for
patch update and never received reply :/.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: patchwork cleanup call

[Frans Meulenbroeks]

2010/10/22 Martin Jansa <martin.jansa@gmail.com>:
> On Fri, Oct 22, 2010 at 09:32:19AM +0200, Frans Meulenbroeks wrote:
>> Nice ideas, but....
>>
>> As far as I see it there are two often occurring situations:
>>
>> - a patch is submitted for review and gets zero feedback. I have quite
>> a few of these in patchwork. I once proposed that if a patch does not
>> get neg feedback in two weeks or so it could be pushed anyway. While
>> this got some positive response it was never really made a policy. But
>> I must say I'm becoming more and more inclined to push them anyway.
>
> Maybe it's not written as policy but as koen said, send ping and if
> still no reply then probably nobody cares it being pushed (so you can
> push it).
>
>> - a patch is submitted by someone without commit access but no one
>> picks up the patch.
>
> ping stating that author has not commit access would be nice
>
>> In either case if patches just get archived without being looked at,
>> it'll probably have an adverse effects.
>
> Agreed
>
>> But we of course still have the problems that
>> - people nak recipes but do not update patchwork
>> - patches receive improvement suggestions and are not updated in patchwork
>> - new versions are posted but patchwork is not updated.
>
> All 3 cases seems like author fault, sometimes I've contacted author for
> patch update and never received reply :/.
>

Guess we should make all these things more explict in the policy (I
think there is a page how to submit patches or so).

BTW: wrt the ack suggestion from koen:

I feel it is silly to ack my own patch.

wrt patches from others without commit access; if it is a patch that
could have been pushed without review if the author had commit access
and I feel comfortable with the patch ("looks sensible"), i'm inclined
to push it on that persons behalf.

and if the patch seems dangerous or is in an area that is way out of
my league, I won't touch it (and won't ack either).

Frans

Re: patchwork cleanup call

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22-10-10 11:15, Frans Meulenbroeks wrote:
> 2010/10/22 Martin Jansa <martin.jansa@gmail.com>:
>> On Fri, Oct 22, 2010 at 09:32:19AM +0200, Frans Meulenbroeks wrote:
>>> Nice ideas, but....
>>>
>>> As far as I see it there are two often occurring situations:
>>>
>>> - a patch is submitted for review and gets zero feedback. I have quite
>>> a few of these in patchwork. I once proposed that if a patch does not
>>> get neg feedback in two weeks or so it could be pushed anyway. While
>>> this got some positive response it was never really made a policy. But
>>> I must say I'm becoming more and more inclined to push them anyway.
>>
>> Maybe it's not written as policy but as koen said, send ping and if
>> still no reply then probably nobody cares it being pushed (so you can
>> push it).
>>
>>> - a patch is submitted by someone without commit access but no one
>>> picks up the patch.
>>
>> ping stating that author has not commit access would be nice
>>
>>> In either case if patches just get archived without being looked at,
>>> it'll probably have an adverse effects.
>>
>> Agreed
>>
>>> But we of course still have the problems that
>>> - people nak recipes but do not update patchwork
>>> - patches receive improvement suggestions and are not updated in patchwork
>>> - new versions are posted but patchwork is not updated.
>>
>> All 3 cases seems like author fault, sometimes I've contacted author for
>> patch update and never received reply :/.
>>
> 
> Guess we should make all these things more explict in the policy (I
> think there is a page how to submit patches or so).
> 
> BTW: wrt the ack suggestion from koen:
> 
> I feel it is silly to ack my own patch.

You ping your own patches
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMwWRzMkyGM64RGpERArNnAJ9XB4aP938QOrinKBdvC8QTYwEc2ACgrNXR
0ssXMRYVQHUqRUJ+hKuwkyw=
=qj4R
-----END PGP SIGNATURE-----

Re: patchwork cleanup call

[Frans Meulenbroeks]

2010/10/22 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 22-10-10 11:15, Frans Meulenbroeks wrote:
>> 2010/10/22 Martin Jansa <martin.jansa@gmail.com>:
>>> On Fri, Oct 22, 2010 at 09:32:19AM +0200, Frans Meulenbroeks wrote:
>>>> Nice ideas, but....
>>>>
>>>> As far as I see it there are two often occurring situations:
>>>>
>>>> - a patch is submitted for review and gets zero feedback. I have quite
>>>> a few of these in patchwork. I once proposed that if a patch does not
>>>> get neg feedback in two weeks or so it could be pushed anyway. While
>>>> this got some positive response it was never really made a policy. But
>>>> I must say I'm becoming more and more inclined to push them anyway.
>>>
>>> Maybe it's not written as policy but as koen said, send ping and if
>>> still no reply then probably nobody cares it being pushed (so you can
>>> push it).
>>>
>>>> - a patch is submitted by someone without commit access but no one
>>>> picks up the patch.
>>>
>>> ping stating that author has not commit access would be nice
>>>
>>>> In either case if patches just get archived without being looked at,
>>>> it'll probably have an adverse effects.
>>>
>>> Agreed
>>>
>>>> But we of course still have the problems that
>>>> - people nak recipes but do not update patchwork
>>>> - patches receive improvement suggestions and are not updated in patchwork
>>>> - new versions are posted but patchwork is not updated.
>>>
>>> All 3 cases seems like author fault, sometimes I've contacted author for
>>> patch update and never received reply :/.
>>>
>>
>> Guess we should make all these things more explict in the policy (I
>> think there is a page how to submit patches or so).
>>
>> BTW: wrt the ack suggestion from koen:
>>
>> I feel it is silly to ack my own patch.
>
> You ping your own patches
> -----BEGIN PGP SIGNATURE-----

Yes, I can and I just did some.

But you wrote:
"And if you're going to push an 'old' unreviewed patch, it's easy enough
to ack it on the ml and wait a bit to see if someone suddenly spots a
huge bug in the patch."

I was commenting on that (and especially the to ack in relation with
my own patches).

FWIW
Frans.

Re: patchwork cleanup call

[Andreas Oberritter]

Hello Frans, hello all,

you're describing the situation very well. I'd like to add some comments
from the perspective of a new contributor.

On 10/22/2010 09:32 AM, Frans Meulenbroeks wrote:
> As far as I see it there are two often occurring situations:
> 
> - a patch is submitted for review and gets zero feedback. I have quite
> a few of these in patchwork. I once proposed that if a patch does not
> get neg feedback in two weeks or so it could be pushed anyway. While
> this got some positive response it was never really made a policy. But
> I must say I'm becoming more and more inclined to push them anyway.
> 
> - a patch is submitted by someone without commit access but no one
> picks up the patch.

Most of my patches got zero feedback. During the last 3-4 weeks, 20 of
my patches were committed, 10 patches are still waiting in patchwork for
a definitive ack or nack or for requests for changes. Of these 10
patches, only 3 got (negative?) feedback:

http://patchwork.openembedded.org/patch/3241/
-> Nack, but no further reply received to my question. IMO, either my
patch is OK or kernel.bbclass is wrong. One must be fixed, but which one
and why?

http://patchwork.openembedded.org/patch/3297/
-> Changes requested. Could be resolved by a patch to
lib_package.bbclass, but there were no further comments about how likely
such a change would be accepted.

http://patchwork.openembedded.org/patch/3338/
-> Question about license raised, unknown state. If someone would like
to look at the source, at least the header files and compat.c don't
include license statements and compat.c looks like code which may be
copied from a library. I guess this one could be committed with GPLv2
and still be updated later if anyone cares enough and is sure about it.

Of the 20 committed patches, only few received feedback either.

I am happy whenever I see a new patch committed, but for me, as a new
contributor, it seems impossible to predict a patch's fate until it
finally gets merged.

Btw., unfortunately, I fear that zero feedback is not limited to
patches, but also happens to apply to questions regarding the
preparation of patches, e.g.:

http://article.gmane.org/gmane.comp.handhelds.openembedded/38203

(2nd part, which I am working around now by (ab?)using ASSUME_PROVIDED)

http://article.gmane.org/gmane.comp.handhelds.openembedded/38591

I can understand that this happens, because the list has so much
traffic. If I don't receive a reply to a mail within 24 hours, then I
don't expect to get a reply at all, be it a patch or a question. Still,
I don't know in which frequency I should ping my patches (or questions,
if still important to me), without spamming or annoying the list.

> In either case if patches just get archived without being looked at,
> it'll probably have an adverse effects.
> The person without commit access will probably stop submitting
> patches, since they do not get accepted.
> And a dev with commit access will stop to send in patches for review
> as they will not get reviewed anyway, and only causes delay, and
> instead push the patches directly.
> 
> Wrt the suggested solutions:
> 
> archiving the patches is just a way to discard them. No one is ever
> going to pick them up from the archive. It'll probably lead to less
> patches and disappointed submitters.
> 
> spamming might help in the case where the submitter has commit access
> and we decide that no feedback during some time is an implicit
> permission to push.
> However in the case the submitter has no commit access it will only
> cause additional grief as the submitter becomes more aware that no one
> bothered to do anything with his patch.
> 
> 
> What would help a little bit is if there is an email on a status
> change. E.g. I just noticed someone assigned two patches to me.
> However, if I hadn't looked into patchwork while typing this message
> it could have easily taken a week before I had noticed (actually it is
> quite possible that they are already a week on my name).

Yes, it would indeed be very helpful, if both the author and the
assignee received emails about status updates by other developers.

> What also would help is identified recipe maintainers. That way it
> becomes clearer who should handle a patch.
> (and I probably would not have gotten those 2 patches, as they are on
> python related stuff and I am a python n00b, guess they should have
> gone to Mickey or so)

Actually, these two patches were delegated to Mickey for about a week
before I delegated them to you. The reason for delegating them to you
was that you stated that you had looked into them, showing some
interest, hoping that you would either commit or redelegate them. ;-)

The most difficult problem for delegation was, however, to find out
nicknames used in patchwork, after searching for maintainers. One needs
to become quite creative to solve this. :-)

> And lastly it would help a little bit if it is stated somewhere if the
> person who pushed it has commit access.
> E.g. if someone without commit access posts a recipe or patch that
> looks good and is not dangerous I sometimes pick it up and push them
> after verifying that they build (e.g. the cd/dvd recipes from Andreas
> Oberritter (sp?) ). If the person posting has commit access, I leave
> it to them to push.
> 
> But we of course still have the problems that
> - people nak recipes but do not update patchwork
> - patches receive improvement suggestions and are not updated in patchwork
> - new versions are posted but patchwork is not updated.

I try to keep patchwork updated, which means that I change states to one
of accepted, rejected, changes requested, superseded or applied, if it's
clear to me which one to choose. Otherwise the state stays at new.

What's a good work flow for using patchwork as a patch submitter?

Regards,
Andreas

Re: patchwork cleanup call

[Frans Meulenbroeks]

2010/10/22 Andreas Oberritter <obi@opendreambox.org>:
> Hello Frans, hello all,
>
> you're describing the situation very well. I'd like to add some comments
> from the perspective of a new contributor.
>
> On 10/22/2010 09:32 AM, Frans Meulenbroeks wrote:
>> As far as I see it there are two often occurring situations:
>>
>> - a patch is submitted for review and gets zero feedback. I have quite
>> a few of these in patchwork. I once proposed that if a patch does not
>> get neg feedback in two weeks or so it could be pushed anyway. While
>> this got some positive response it was never really made a policy. But
>> I must say I'm becoming more and more inclined to push them anyway.
>>
>> - a patch is submitted by someone without commit access but no one
>> picks up the patch.
>
> Most of my patches got zero feedback. During the last 3-4 weeks, 20 of
> my patches were committed, 10 patches are still waiting in patchwork for
> a definitive ack or nack or for requests for changes. Of these 10
> patches, only 3 got (negative?) feedback:
>
> http://patchwork.openembedded.org/patch/3241/
> -> Nack, but no further reply received to my question. IMO, either my
> patch is OK or kernel.bbclass is wrong. One must be fixed, but which one
> and why?
>
> http://patchwork.openembedded.org/patch/3297/
> -> Changes requested. Could be resolved by a patch to
> lib_package.bbclass, but there were no further comments about how likely
> such a change would be accepted.
>
> http://patchwork.openembedded.org/patch/3338/
> -> Question about license raised, unknown state. If someone would like
> to look at the source, at least the header files and compat.c don't
> include license statements and compat.c looks like code which may be
> copied from a library. I guess this one could be committed with GPLv2
> and still be updated later if anyone cares enough and is sure about it.
>
> Of the 20 committed patches, only few received feedback either.
>
> I am happy whenever I see a new patch committed, but for me, as a new
> contributor, it seems impossible to predict a patch's fate until it
> finally gets merged.
>
> Btw., unfortunately, I fear that zero feedback is not limited to
> patches, but also happens to apply to questions regarding the
> preparation of patches, e.g.:
>
> http://article.gmane.org/gmane.comp.handhelds.openembedded/38203
>
> (2nd part, which I am working around now by (ab?)using ASSUME_PROVIDED)
>
> http://article.gmane.org/gmane.comp.handhelds.openembedded/38591
>
> I can understand that this happens, because the list has so much
> traffic. If I don't receive a reply to a mail within 24 hours, then I
> don't expect to get a reply at all, be it a patch or a question. Still,
> I don't know in which frequency I should ping my patches (or questions,
> if still important to me), without spamming or annoying the list.
>
>> In either case if patches just get archived without being looked at,
>> it'll probably have an adverse effects.
>> The person without commit access will probably stop submitting
>> patches, since they do not get accepted.
>> And a dev with commit access will stop to send in patches for review
>> as they will not get reviewed anyway, and only causes delay, and
>> instead push the patches directly.
>>
>> Wrt the suggested solutions:
>>
>> archiving the patches is just a way to discard them. No one is ever
>> going to pick them up from the archive. It'll probably lead to less
>> patches and disappointed submitters.
>>
>> spamming might help in the case where the submitter has commit access
>> and we decide that no feedback during some time is an implicit
>> permission to push.
>> However in the case the submitter has no commit access it will only
>> cause additional grief as the submitter becomes more aware that no one
>> bothered to do anything with his patch.
>>
>>
>> What would help a little bit is if there is an email on a status
>> change. E.g. I just noticed someone assigned two patches to me.
>> However, if I hadn't looked into patchwork while typing this message
>> it could have easily taken a week before I had noticed (actually it is
>> quite possible that they are already a week on my name).
>
> Yes, it would indeed be very helpful, if both the author and the
> assignee received emails about status updates by other developers.
>
>> What also would help is identified recipe maintainers. That way it
>> becomes clearer who should handle a patch.
>> (and I probably would not have gotten those 2 patches, as they are on
>> python related stuff and I am a python n00b, guess they should have
>> gone to Mickey or so)
>
> Actually, these two patches were delegated to Mickey for about a week
> before I delegated them to you. The reason for delegating them to you
> was that you stated that you had looked into them, showing some
> interest, hoping that you would either commit or redelegate them. ;-)
>
> The most difficult problem for delegation was, however, to find out
> nicknames used in patchwork, after searching for maintainers. One needs
> to become quite creative to solve this. :-)
>
>> And lastly it would help a little bit if it is stated somewhere if the
>> person who pushed it has commit access.
>> E.g. if someone without commit access posts a recipe or patch that
>> looks good and is not dangerous I sometimes pick it up and push them
>> after verifying that they build (e.g. the cd/dvd recipes from Andreas
>> Oberritter (sp?) ). If the person posting has commit access, I leave
>> it to them to push.
>>
>> But we of course still have the problems that
>> - people nak recipes but do not update patchwork
>> - patches receive improvement suggestions and are not updated in patchwork
>> - new versions are posted but patchwork is not updated.
>
> I try to keep patchwork updated, which means that I change states to one
> of accepted, rejected, changes requested, superseded or applied, if it's
> clear to me which one to choose. Otherwise the state stays at new.
>
> What's a good work flow for using patchwork as a patch submitter?
>
> Regards,
> Andreas
>

Hi Andreas,

Thanks for the feedback, and don't hesitate to bother people if you do
not get a reply.

To give some answers to your questions:
Wrt LICENSE: this will (quite likely) be discussed at the OE dev
meeting (OEDEM) next week fri/sat.

Wrt names: maybe we should indeed have a list somewhere. No idea if
people would want that., will try to raise it next week too.

As far as the patches concerns: I don't really feel too comfortable
when it comes to core .bbclass files; I'm not really a python wiz, so
I can't comment on them and as they influence the whole build system
I'm not going to push them without acks.

Your new cddb related patches, I've peeked into and pushed them.
Didn't really give feedback that I did. Then again if it got pushed
without comments, someone must have felt it was ok.

What also helps (and is a good source for answers) is irc.
If you join the #oe chatroom in irc there is often someone around who
can help you or point you in the right direction. Feel free to join us
over there.
(that also would help resolving names, if you've asked about me
definitely someone would have responded eFfeM. (which is actually
constructed from my initials but FM was already taken)

Best regards & thanks for your contributions! They are really valued
and (at least IMHO) of very good quality.

Frans

Re: patchwork cleanup call

[Khem Raj]

On Fri, Oct 22, 2010 at 5:42 AM, Andreas Oberritter
<obi@opendreambox.org> wrote:
> Hello Frans, hello all,
>
> you're describing the situation very well. I'd like to add some comments
> from the perspective of a new contributor.
>
> On 10/22/2010 09:32 AM, Frans Meulenbroeks wrote:
>> As far as I see it there are two often occurring situations:
>>
>> - a patch is submitted for review and gets zero feedback. I have quite
>> a few of these in patchwork. I once proposed that if a patch does not
>> get neg feedback in two weeks or so it could be pushed anyway. While
>> this got some positive response it was never really made a policy. But
>> I must say I'm becoming more and more inclined to push them anyway.
>>
>> - a patch is submitted by someone without commit access but no one
>> picks up the patch.
>
> Most of my patches got zero feedback. During the last 3-4 weeks, 20 of
> my patches were committed, 10 patches are still waiting in patchwork for
> a definitive ack or nack or for requests for changes. Of these 10
> patches, only 3 got (negative?) feedback:
>
> http://patchwork.openembedded.org/patch/3241/
> -> Nack, but no further reply received to my question. IMO, either my
> patch is OK or kernel.bbclass is wrong. One must be fixed, but which one
> and why?
>
> http://patchwork.openembedded.org/patch/3297/
> -> Changes requested. Could be resolved by a patch to
> lib_package.bbclass, but there were no further comments about how likely
> such a change would be accepted.
>
> http://patchwork.openembedded.org/patch/3338/
> -> Question about license raised, unknown state. If someone would like
> to look at the source, at least the header files and compat.c don't
> include license statements and compat.c looks like code which may be
> copied from a library. I guess this one could be committed with GPLv2
> and still be updated later if anyone cares enough and is sure about it.
>
> Of the 20 committed patches, only few received feedback either.
>
> I am happy whenever I see a new patch committed, but for me, as a new
> contributor, it seems impossible to predict a patch's fate until it
> finally gets merged.
>
> Btw., unfortunately, I fear that zero feedback is not limited to
> patches, but also happens to apply to questions regarding the
> preparation of patches, e.g.:
>
> http://article.gmane.org/gmane.comp.handhelds.openembedded/38203
>
> (2nd part, which I am working around now by (ab?)using ASSUME_PROVIDED)
>
> http://article.gmane.org/gmane.comp.handhelds.openembedded/38591
>
> I can understand that this happens, because the list has so much
> traffic. If I don't receive a reply to a mail within 24 hours, then I
> don't expect to get a reply at all, be it a patch or a question. Still,
> I don't know in which frequency I should ping my patches (or questions,
> if still important to me), without spamming or annoying the list.
>
>> In either case if patches just get archived without being looked at,
>> it'll probably have an adverse effects.
>> The person without commit access will probably stop submitting
>> patches, since they do not get accepted.
>> And a dev with commit access will stop to send in patches for review
>> as they will not get reviewed anyway, and only causes delay, and
>> instead push the patches directly.
>>
>> Wrt the suggested solutions:
>>
>> archiving the patches is just a way to discard them. No one is ever
>> going to pick them up from the archive. It'll probably lead to less
>> patches and disappointed submitters.
>>
>> spamming might help in the case where the submitter has commit access
>> and we decide that no feedback during some time is an implicit
>> permission to push.
>> However in the case the submitter has no commit access it will only
>> cause additional grief as the submitter becomes more aware that no one
>> bothered to do anything with his patch.
>>
>>
>> What would help a little bit is if there is an email on a status
>> change. E.g. I just noticed someone assigned two patches to me.
>> However, if I hadn't looked into patchwork while typing this message
>> it could have easily taken a week before I had noticed (actually it is
>> quite possible that they are already a week on my name).
>
> Yes, it would indeed be very helpful, if both the author and the
> assignee received emails about status updates by other developers.
>
>> What also would help is identified recipe maintainers. That way it
>> becomes clearer who should handle a patch.
>> (and I probably would not have gotten those 2 patches, as they are on
>> python related stuff and I am a python n00b, guess they should have
>> gone to Mickey or so)
>
> Actually, these two patches were delegated to Mickey for about a week
> before I delegated them to you. The reason for delegating them to you
> was that you stated that you had looked into them, showing some
> interest, hoping that you would either commit or redelegate them. ;-)
>
> The most difficult problem for delegation was, however, to find out
> nicknames used in patchwork, after searching for maintainers. One needs
> to become quite creative to solve this. :-)
>
>> And lastly it would help a little bit if it is stated somewhere if the
>> person who pushed it has commit access.
>> E.g. if someone without commit access posts a recipe or patch that
>> looks good and is not dangerous I sometimes pick it up and push them
>> after verifying that they build (e.g. the cd/dvd recipes from Andreas
>> Oberritter (sp?) ). If the person posting has commit access, I leave
>> it to them to push.
>>
>> But we of course still have the problems that
>> - people nak recipes but do not update patchwork
>> - patches receive improvement suggestions and are not updated in patchwork
>> - new versions are posted but patchwork is not updated.
>
> I try to keep patchwork updated, which means that I change states to one
> of accepted, rejected, changes requested, superseded or applied, if it's
> clear to me which one to choose. Otherwise the state stays at new.
>
> What's a good work flow for using patchwork as a patch submitter?

well you submit your patches and start the counter. If it does not get
attention then there could be many reasons
and you have to keep reminding the list. But getting patches to list
and reviewed is absolutely a step towards
good quality. OE is relatively OK in applying them. Developers need to
help a bit and it takes time to test them out.

> Regards,
> Andreas
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>