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