linuxppc patchwork queue

linuxppc patchwork queue

[Denis Kirjanov]

Hi guys,

As we all know we have a great tool to track the patch queue - patchwork.
The sad thing is that it's maintained not good as it could be. The
netdev patchwork is a great example of how it can be done and I bet
everyone would love to see the ppc patch queue like that.

So can we improve the current situation? I'd love to help in any way possible.

Thank you!

Re: linuxppc patchwork queue

[Michael Ellerman]

Hi Denis,

On Fri, 2015-11-20 at 17:48 +0300, Denis Kirjanov wrote:
> Hi guys,
> 
> As we all know we have a great tool to track the patch queue - patchwork.
> The sad thing is that it's maintained not good as it could be. The
> netdev patchwork is a great example of how it can be done and I bet
> everyone would love to see the ppc patch queue like that.

What exactly is wrong with it?

I try pretty hard to keep it up to date with the state of what's happening in
my tree. I'm fairly sure that everything I merged for 4.4 has been marked
accepted.

There are a lot of new patches there at the moment, but that's mainly because I
haven't started merging things for 4.5 yet.

> So can we improve the current situation? I'd love to help in any way
> possible.

You could send fewer patches ;)

cheers

Re: linuxppc patchwork queue

[Denis Kirjanov]

On 11/23/15, Michael Ellerman <mpe@ellerman.id.au> wrote:
> Hi Denis,
>
> On Fri, 2015-11-20 at 17:48 +0300, Denis Kirjanov wrote:
>> Hi guys,
>>
>> As we all know we have a great tool to track the patch queue - patchwork.
>> The sad thing is that it's maintained not good as it could be. The
>> netdev patchwork is a great example of how it can be done and I bet
>> everyone would love to see the ppc patch queue like that.
>
> What exactly is wrong with it?

I just wanted to point out that we have some patches without any reply like
https://patchwork.ozlabs.org/patch/518981/ or patches since 2010.

>
> I try pretty hard to keep it up to date with the state of what's happening
> in
> my tree. I'm fairly sure that everything I merged for 4.4 has been marked
> accepted.

Nothing personal, I see that you made a good progress with it because
I remember how it looked like a few years ago.

>
> There are a lot of new patches there at the moment, but that's mainly
> because I
> haven't started merging things for 4.5 yet.
>
>> So can we improve the current situation? I'd love to help in any way
>> possible.
>
> You could send fewer patches ;)

I could, but I want make it better :)

Thanks!

>
> cheers
>
>

Re: linuxppc patchwork queue

[Michael Ellerman]

On Mon, 2015-11-23 at 12:45 +0300, Denis Kirjanov wrote:
> On 11/23/15, Michael Ellerman <mpe@ellerman.id.au> wrote:
> > Hi Denis,
> > 
> > On Fri, 2015-11-20 at 17:48 +0300, Denis Kirjanov wrote:
> > > Hi guys,
> > > 
> > > As we all know we have a great tool to track the patch queue - patchwork.
> > > The sad thing is that it's maintained not good as it could be. The
> > > netdev patchwork is a great example of how it can be done and I bet
> > > everyone would love to see the ppc patch queue like that.
> > 
> > What exactly is wrong with it?
> 
> I just wanted to point out that we have some patches without any reply like
> https://patchwork.ozlabs.org/patch/518981/ or patches since 2010.

OK.

518981 was part of a big series adding that stuff to lots of drivers. I was
waiting to see if someone was picking up the whole series, or if I was expected
to. I'll put those in this merge window.

It's true we have some old stuff lying around. Some of them are things we still
mean to look at, but just haven't had time, and others are just old junk that
we never get around to. I generally work from the top of the list and never get
to the bottom :)

And most of those old patches are delegated to Benh & Scottwood anyway ;)

> > > So can we improve the current situation? I'd love to help in any way
> > > possible.
> > 
> > You could send fewer patches ;)
> 
> I could, but I want make it better :)

Yeah that was a bit sarcastic of me :)

The main thing you could do, and anyone could do (!), is just review some
patches. Even if you don't know the area of code that well, you can usually do
a basic review.

eg. Just the basic stuff:
 - Is the subject correctly formatted and makes sense.
 - Is the change log well written and describes the change well.
 - Does the patch do one logical change.
 - Are there any obviously bad coding style things.
 - Can you follow the basics of the change based on the change log and some
   reading of the code?

Another thing I seem to spend a lot of time on is asking people if their patch
should go to stable or not, and if so what versions. So everyone could help out
there.

cheers

Re: linuxppc patchwork queue

[Daniel Axtens]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

> The main thing you could do, and anyone could do (!), is just review some
> patches. Even if you don't know the area of code that well, you can usually do
> a basic review.
>
> eg. Just the basic stuff:
>  - Is the subject correctly formatted and makes sense.
>  - Is the change log well written and describes the change well.
>  - Does the patch do one logical change.
>  - Are there any obviously bad coding style things.
>  - Can you follow the basics of the change based on the change log and some
>    reading of the code?

Michael gave me the same advice earlier this year, and I found it really
helpful. As a result, I've been trying to do reviews.

I am by no means an expert, but here's what I found starting out:

 - Reviewing is a learned skill - you don't just start doing kernel dev
   and get this magical sense of how to do reviews. This means it's OK
   to start small, and that no-one expects your early reviews to be
   amazing.

 - Reviewing gets much easier when you just jump in and start doing it!

 - A review doesn't have to focus on getting to a reviewed-by
   tag. Asking good questions is equally if not more valuable.

 - It was easier to start with the 'little picture', or what Michael
   calls the 'basic stuff'. Is it good C? Does the commit message make
   sense? Is the spelling right? Does it do weird things without
   explaining them? When you're starting it's OK to leave the 'big
   picture'/architectural/design reviews to other people. I definitely
   still do!

HTH.
Daniel

>
> Another thing I seem to spend a lot of time on is asking people if their patch
> should go to stable or not, and if so what versions. So everyone could help out
> there.
>
> cheers
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 859 bytes --]

Re: linuxppc patchwork queue

[Michael Ellerman]

On Tue, 2015-11-24 at 08:56 +1100, Daniel Axtens wrote:
> > The main thing you could do, and anyone could do (!), is just review some
> > patches. Even if you don't know the area of code that well, you can usually do
> > a basic review.
> > 
> > eg. Just the basic stuff:
> >  - Is the subject correctly formatted and makes sense.
> >  - Is the change log well written and describes the change well.
> >  - Does the patch do one logical change.
> >  - Are there any obviously bad coding style things.
> >  - Can you follow the basics of the change based on the change log and some
> >    reading of the code?
> 
> Michael gave me the same advice earlier this year, and I found it really
> helpful. As a result, I've been trying to do reviews.
> 
> I am by no means an expert, but here's what I found starting out:
> 
>  - Reviewing is a learned skill - you don't just start doing kernel dev
>    and get this magical sense of how to do reviews. This means it's OK
>    to start small, and that no-one expects your early reviews to be
>    amazing.

Yes!

>  - Reviewing gets much easier when you just jump in and start doing it!
> 
>  - A review doesn't have to focus on getting to a reviewed-by
>    tag. Asking good questions is equally if not more valuable.

Absolutely.

In fact I'm usually a bit sceptical of reviews that are only a Reviewed-by tag,
because that gives me no evidence that the reviewer actually reviewed it.

I'd much rather some questions and/or comments. Even if the patch is perfect,
there's almost always something that you can comment on. Even if it's just
observations like "this logic confused me until I realised X which makes it
work".

>  - It was easier to start with the 'little picture', or what Michael
>    calls the 'basic stuff'. Is it good C? Does the commit message make
>    sense? Is the spelling right? Does it do weird things without
>    explaining them? When you're starting it's OK to leave the 'big
>    picture'/architectural/design reviews to other people. I definitely
>    still do!

Yes exactly. Often just starting to review those things will give you enough
insight into the patch to start understanding it a bit more, or at the very
least you prompt the author into explaining what they're doing better, which is
almost always helpful.

cheers