Development procedures

Hi everybody,

after some discussion with several people contributing to RIOT, we came up with the following rules for the development procedure:

1. Check if your code follows the coding conventions    (https://github.com/RIOT-OS/RIOT/wiki/Coding-conventions). If the code    does not comply these style rules, your code will not be merged.

2. Create a new branch in your own fork for every new feature or fix.    Then create the pull request from this branch, once you completed your    task (feature or fix). Every commit in this branch will be added to the    pull request.

3. Master branch will be our "stable branch". Main reason is that new users    will probably just checkout the Github master. This should always be in a    working state. The RIOT maintainers will create release tags based on this    branch, whenever a milestone is completed.

4. There'll be a "devel" branch including the newest features. This should    *always compile* as well.

5. New features and fixes will always be submitted as pull requests. A pull    request will be merged if the RIOT maintainers acknowledge the request.    Before it will get merged, the pull request has to stay open long enough    to discuss possible issues, but no longer than 30 days. The more extensive    the changes in the pull request, the more time should be given for    discussion.

6. Comments on a pull request should be added to the request itself, and    *not* to the commit.

7. Only RIOT maintainers have commit rights to the main RIOT repository.    However, even they have to create pull requests to submit their changes. A    RIOT contributor cannot acknowledge his own pull request. All current RIOT    maintainers are listed in the wiki.

8. Keep commits to the point, e.g., don't add whitespace/typo fixes to other    code changes. If changes are layered, layer the patches.

9. Describe the technical detail of the change(s) as specific as possible.

Cheers, Oleg

Hi,

Hi Martin!

> 5. New features and fixes will always be submitted as pull requests. A > pull request will be merged if the RIOT maintainers acknowledge the > request. Before it will get merged, the pull request has to stay open > long enough to discuss possible issues, but no longer than 30 days. The > more extensive the changes in the pull request, the more time should be > given for discussion. > > Is there a minimum number (greater than 1, of course) of ACKs a pull request must receive?

Actually, we did not specify any number of required ACKs on purpose. The idea is to keep these rules simple and flexible. If the PR contains severe changes or complex code, it should be reviewed by more people and left open longer for discussion. However, a small change could get merged after a short while with only one ACK.

Cheers, Oleg