linuxppc patchwork queue

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!

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

On 11/23/15, Michael Ellerman [off-list ref] wrote:

Hi Denis,

On Fri, 2015-11-20 at 17:48 +0300, Denis Kirjanov wrote:

quoted

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.

quoted

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

On Mon, 2015-11-23 at 12:45 +0300, Denis Kirjanov wrote:

On 11/23/15, Michael Ellerman [off-list ref] wrote:

quoted

Hi Denis,

On Fri, 2015-11-20 at 17:48 +0300, Denis Kirjanov wrote:

quoted

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 ;)

quoted

quoted

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

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

On Tue, 2015-11-24 at 08:56 +1100, Daniel Axtens wrote:

quoted

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