Download as
Browse Code »

Commit 2ee317d975f0544f884e49b35164e9dfe6dde05e

Authored by Antonio Terceiro
1 parent 46f264fa
Exists in master and in 21 other branches activate_plugin, api_fixies, api_tasks, article_blog_visualization_format, article_layout_refactoring, article_layout_temp, blog_page_bug, clone_article, communities_ratings, design_template, event_layout, fix_forum, fix_optional_fields, fix_suggest_article, folder_improvments, manage_organization, news_page, script_to_update, template_mirror_block, tests, tests_fixies

Noosfero development policy

Showing 1 changed file with 101 additions and 0 deletions   Show diff stats
DEVELOPMENT.md 0 → 100644
  Diff comments   View file @2ee317d
... ... @@ -0,0 +1,101 @@
  1 +# Noosfero Development Policy
  2 +
  3 +## Developer Roles
  4 +
  5 +* *Developers* are everyone that are contributing code to Noosfero.
  6 +* *Committers* are the people with direct commit access to the Noosfero source
  7 + code. They are responsible for reviewing contributions from other developers
  8 + and integrating them in the Noosfero code base. They are the members of the
  9 + [Noosfero group on Gitlab](https://gitlab.com/groups/noosfero/members).
  10 +* *Release managers* are the people that are managing the release of a new
  11 + Noosfero version and/or the maintainance work of an existing Noosfero stable
  12 + branch. See MAINTAINANCE.md for details on the maintaince policy.
  13 +
  14 +## Development process
  15 +
  16 +* Every new feature or non-trivial bugfix should be reviewed by at least one
  17 + committer. This must be the case even if the original author is a committer.
  18 +
  19 + * In the case the original author is a committer, he/she should feel free to
  20 + commit directly if after 1 week nobody has provided any kind of feedback.
  21 +
  22 +* Committers should feel free to push trivial (or urgent) changes directly.
  23 + There are no strict rule on what makes a change trivial or urgent; committers
  24 + are expected to exercise good judgement on a case by case basis.
  25 +
  26 +* In the case of unsolvable conflict between commiters regarding any change to
  27 + the code, the current release manager(s) will have the final say in the
  28 + matter.
  29 +
  30 +* Release managers are responsible for stablishing a release schedule, and
  31 + about deciding when and what to release.
  32 +
  33 + * Release managers should announce release schedules to the project mailing
  34 + lists in advance.
  35 +
  36 + * The release schedule may include a period of feature freeze, during which
  37 + no new features or any other changes that are not pre-approved by the
  38 + release manager must be committed to the repository. Committers must
  39 + respect the feature freezes.
  40 +
  41 +## Maintainance process
  42 +
  43 +### Not all feature releases will be maintained as a stable release
  44 +
  45 +We will be choosing specific release series to be maintained as stable
  46 +releases.
  47 +
  48 +This means that a given release is not guaranteed to be maintained as a stable
  49 +release, but does *not* mean it won't be. Any committer (or anyone, really) can
  50 +decide to maintain a given release as stable and seek help from others to do
  51 +so.
  52 +
  53 +### No merges from stable branches to master
  54 +
  55 +*All* changes must be submitted against the master branch first, and when
  56 +applicable, backported to the desired stable releases. Exceptions to this rules
  57 +are bug fixes that only apply to a given stable branch and not to master.
  58 +
  59 +In the past we had non-trivial changes accepted into stable releases while
  60 +master was way ahead (e.g. during the rails3 migration period), that made the
  61 +merge back into master very painful. By eliminating the need to do these
  62 +merges, we save time for the people responsible for the release, and eliminate
  63 +the possibility of human errors or oversights causing changes to be accepted
  64 +into stable that will be a problem to merge back into master.
  65 +
  66 +By getting all fixes in master first, we improve the chances that a future
  67 +release will not present regressions against bugs that should already be fixed,
  68 +but the fixes got lost in a big, complicated merge (and those won't exist
  69 +anymore, at least not from stable branches to master).
  70 +
  71 +After a fix gets into master, backporting changes into a stable release branch
  72 +is the responsibility of whoever is maintaing that branch, and those interested
  73 +in it. The stable branch release manager(s) are entitled the final say on any
  74 +matters related to that branch.
  75 +
  76 +## Apendix A: how to become a committer
  77 +
  78 +Every developer that wants to be a committer should create [an issue on
  79 +Gitlab](https://gitlab.com/noosfero/noosfero/issues) requesting to be added as
  80 +a committer. This request must include information the requestor's previous
  81 +contributions to the project.
  82 +
  83 +If 2 or more commiters consider second the request, the requestor is accepted
  84 +as new commiter and added to the Noosfero group.
  85 +
  86 +The existing committers are free to choose whatever criteria they want to
  87 +second the request, but they must be sure that the new committer is a
  88 +responsible developer and knows what she/he is doing. They must be aware that
  89 +seconding these requests means seconding the actions of the new committer: if
  90 +the new committer screw up, her/his seconds screwed up.
  91 +
  92 +## Apendix B: how to become a release manager
  93 +
  94 +A new release manager for the development version of Noosfero (i.e. the one
  95 +that includes new features, a.k.a. the master branch) is apointed by the
  96 +current release manager, and must be a committer first.
  97 +
  98 +Release managers for stable branches are self-appointed, i.e. whoever takes the
  99 +work takes the role. In case of a conflict (e.g. 2+ different people want to
  100 +the work but can't agree on working together), the development release manager
  101 +decides.
... ...