From BlenderWiki

Jump to: navigation, search

Just an FYI regarding patches

we've spent the last two sunday meetings doing almost only patch review. It is likely that we will try and switch to some sort of regularly scheduled patch review, maybe every other sunday or such (right now we are in 'catchup' mode). We do appreciate patches and we do realize that it is frustrating to submit a patch and see it not being reviewed in a quick manner. We are working on making the process faster and more apparent what exactly happens when. We've also been adding more people who are can review and commit patches.

[edit] speeding the patch process

Some ways to help your code get more quickly accepted are to

  1. patch content
    1. follow code guidelines
    2. no new warnings and preferably clean up old warnings
    3. comment your code. Describe why or how you are doing something. New functions and methods need a block comment describing what they do.
    4. if it will be used by end users please add a page documenting usage at the wiki
    5. for Blender Python (BPy) patches we will insist on documentation. Format is epydoc (looks like python + markup ). See the api2_2x/doc directory for source.
    6. include a test case; either a .blend or a script that demonstrates and tests the functionality you are adding or fixing. You did test your patch, right?
  2. getting the patch out there
    1. do diff -U and make sure it doesn't include code that is meant for a different patch and make sure all of the files needed are in it
    2. try and have your patches 'small and independent' a big patch means a big review, which will require a big chunk of free time for the patch reviewer
    3. put in patch tracker
    4. optionally create testing builds and have people test them (there is free hosting for blender testing builds see the testing forum for details)
  3. optionally (but preferably) show up at Sunday meetings so that
    1. you can request your patch be part of the meeting agenda or for post meeting review and
    2. so you can answer any questions if there are any that arrise in relation to your patch

[edit] Reviewers need time

Realize that occassionally the person who 'owns' the code you've submitted a patch for may not be available for review. For instance there are many pieces of code that Ton is maintainer of thus there are a number of patches he has on his 'todo' list that he can only rarely find time to do reviews (animation system, renderer, materials, nodes). We might add as a goal to have at least two people for each section that can do patch reviews for that section but we need to be positive that the person has the skills and commitment willing to do good reviews (rather than 'yep it compiles' :) )

[edit] getting commit rights

For those interested in commit rights - basically there is a group of four individials that has to approve all new committers also if you are being given commit rights where another individual is already a maintainer it requires the maintainers permission as well.

The basic method to get commit rights is to submit many and useful quality patches that show that you have a good understanding of the relevant code (ie they shouldn't be buggy patches with yucky style and ten times too long to do what is wanted) even better is being someone who has a demonstrated willingness to fix bugs (a good example of this was Ken Hughes). Also it is good to show that you can work with the team some ways of showing this are

  • 1) respond to criticism and suggestions regarding your code in a professional and well reasoned manner (Peter Schaile was a recent excellent example)
  • 2) make reasonable changes that are requrested or explain why the changes isn't reasonable/feasible
  • 3) that your patches don't add warnings (and preferably remove warnings that already existed in that code area) and that any warnings found after you commit are cleaned up quickly.
Retrieved from "http://wiki.blender.org/index.php/Dev:Doc/Patches_and_Commit_Rights"