Permalink
Switch branches/tags
debian/2.10.0+rc4 debian/2.10.0+rc3 debian/2.10.0+rc2 debian/2.10.0+rc1 debian/2.10.0+rc0 debian/2.8.1+rc0 debian/2.8.0+thefinal0 debian/2.8.0+rc13 debian/2.8.0+rc12 debian/2.8.0+rc11 debian/2.8.0+rc10 debian/2.8.0+rc9 debian/2.8.0+rc8 debian/2.8.0+rc7 debian/2.8.0+rc6 debian/2.8.0+rc5 debian/2.8.0+rc4 debian/2.8.0+rc3 debian/2.8.0+rc2 debian/2.8.0+rc1 debian/2.8.0+rc0 debian/2.7.5+dev20180124154147 debian/2.7.5+dev20180123112419 debian/2.7.4+dev20171114153121 debian/2.7.2+dev20171013181704 debian/2.7.1+dev20171013111656 debian/2.7.0+thefinal0 debian/2.6.3+thefinal0 debian/2.6.2+thefinal0 debian/2.6.1+thefinal0 debian/2.6.0+thefinal0 debian/2.6.0+rc1 debian/2.6.0+beta1 debian/2.6.0+alpha1 debian/2.5.15+thefinal0 debian/2.5.14+thefinal0 debian/2.5.13+thefinal0 debian/2.5.12+thefinal0 debian/2.5.11+thefinal0 debian/2.5.10+thefinal0 debian/2.5.9+thefinal5 debian/2.5.9+thefinal4 debian/2.5.9+thefinal3 debian/2.5.9+thefinal2 debian/2.5.9+thefinal1 debian/2.5.9+thefinal0 debian/2.5.9+dev20170116091118 debian/2.5.7+thefinal0 debian/2.5.6+thefinal0 debian/2.5.5+thefinal0 debian/2.5.4+thefinal0 debian/2.5.3+thefinal0 debian/2.5.2+thefinal0 debian/2.5.1+thefinal0 debian/2.5.0+thefinal0 debian/2.4.1+thefinal1 debian/2.4.0+thefinal0 debian/2.4.0+rc4 debian/2.4.0+rc3 debian/2.4.0+rc2 debian/2.4.0+rc1 debian/2.4.0+dev20141024171719 debian/2.4.0+beta28 debian/2.4.0+beta27 debian/2.4.0+beta26 debian/2.4.0+beta25 debian/2.4.0+beta24 debian/2.4.0+beta23 debian/2.4.0+beta22 debian/2.4.0+beta21 debian/2.4.0+beta20 debian/2.4.0+beta19 debian/2.4.0+beta18 debian/2.4.0+beta17 debian/2.4.0+beta16 debian/2.4.0+beta15 debian/2.4.0+beta14 debian/2.4.0+beta13 debian/2.4.0+beta12 debian/2.4.0+beta11 debian/2.4.0+beta10 debian/2.4.0+beta9 debian/2.4.0+beta8 debian/2.4.0+beta7 debian/2.4.0+beta6 debian/2.4.0+beta5 debian/2.4.0+beta4 debian/2.4.0+beta3 debian/2.4.0+beta2 debian/2.4.0+beta1 debian/2.4.0+alpha38 debian/2.4.0+alpha37 debian/2.4.0+alpha36 debian/2.4.0+alpha35 debian/2.4.0+alpha34 debian/2.4.0+alpha33 debian/2.4.0+alpha32 debian/2.4.0+alpha31 debian/2.4.0+alpha30 debian/2.4.0+alpha29
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
56 lines (37 sloc) 3.54 KB
.. _review_process:
GeoNode Patch Review Process
============================
This document outlines the code review process for GeoNode code.
Each commit proposed for inclusion in GeoNode should be reviewed by at least one developer other than the author.
For pragmatic reasons, some developers, referred to in this document as *core committers*, may commit directly to the GeoNode repository without waiting for review.
Such changes are still subject to review, and may be reverted if they fail any of the [[Review Criteria]].
A related process is [[Improvement Proposals]].
While patch review protects code quality in the GeoNode project at a small granularity, the Improvement Proposal process is intended to promote coordinated design and feedback for larger modifications such as new features or architectural changes.
Goals
-----
By requiring a review of code coming into GeoNode, we aim to maintain code quality within the GeoNode project while still allowing contributions from the GeoNode community.
Review Criteria
---------------
Patch reviews should adhere to the standards set in the [[Review Criteria]], a [[Project Steering Committee]] approved set of criteria for the inclusion of new code.
Process
-------
For contributors who do not have commit access to the GeoNode repository, the review process is as follows:
0. Find or create a ticket describing the feature or bug to be resolved.
1. Create changes to GeoNode code addressing the ticket.
2. Publish those changes and request a review from the GeoNode committers.
The recommended format is a GitHub [pull request](https://help.github.com/articles/about-pull-requests/).
If you are unable or unwilling to provide a change as a branch on GitHub, please consult the developer's list for advice.
3. At least one GeoNode committer should review the submitted changes.
If he finds the patch acceptable, the changes will be pulled into GeoNode.
If problems are found, then he should list them clearly in order to allow the original author to update the submission (at which point we return to point 2 in this process.)
In the case of a feature idea which is simply not suitable for inclusion as core GeoNode functionality, the patch may be rejected outright.
_Note: If after a few days your patch has not been reviewed by any GeoNode committer, please feel free to bring it up either in the mailing list or the IRC channel. The GeoNode community (and it's committers) try to respond quickly and give adequate feedback to maintain the interest of new potential members. However, sometimes other responsibilities prevent us from responding quickly._
Core Committers
---------------
It is assumed that core committers are familiar with the quality guidelines and capable of producing acceptable patches without the need for waiting on review.
Therefore, core committers may make changes without requesting review first (although they are welcome to request review for code if they feel it is appropriate.)
For commits made without prior review, committers should review the changes and revert them if they are in violation of the project quality guidelines.
Becoming a Core Committer
-------------------------
In order for a developer to become a core committer, he must demonstrate familiarity with the quality guidelines for the GeoNode project by producing at least two patches which successfully pass review and are merged without requiring modification.
A candidate for core committer-ship must be nominated by a member of the [[Project Steering Committee]], and approved via Apache consensus voting among PSC members.