> 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
signature.asc
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
