wiki:en/process
developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Version 2 (modified by doubleface, 13 years ago) (diff)

--

The development process

The Jelix development process aims to drive to a quality developement.

The actors

Among the Jelix developpers, there are :

  • The contributors : they contribute by proposing patches, improvements. They don't have write access in the subversion repository.
  • The commiters : the regulqr contributors, those that "proved theselves" to be valuable. They have write access to the subversion repository. They are part of the project's team.
  • The reviewers : these are the commiters thar review the patches before giving agreement for commit. They necessarily deeply know the code of Jelix.
  • The projet leader : He is warant of the respect to the roadmap, the consistency of the framework. He ensures that the changes are consistent with the objectives of the framework (lightness, performance, simplicity).
  • Les contributeurs : ils contribuent en proposant des patchs, des améliorations. Ils ne peuvent accéder en écriture au dépôt subversion.
  • Les "commiters" : les contributeurs réguliers, ceux qui ont fait "leur preuves". Ils ont accés en écriture au dépôt subversion. Ils font parti de l'équipe de développement du projet.
  • Les "reviewers" : ce sont des commiters qui relisent des patchs avant de donner l'accord d'un commit. Ils connaissent nécessairement le code de jelix en profondeur.
  • Le "projet leader" : celui qui a le dernier mot :-) Il est le garant du respect de la roadmap, de la cohérence du framework. Il s'assure que les évolutions sont compatibles avec les objectifs premiers du framework (légèreté, performance, simplicité).

The process

  • a contributor or a commiter propose a patch
  • a reviewer must review the code, check that the code respects the conventions, that it is optimized etc. Any modification must pass by a reviewer before being committed.
  • Any new features must also be approved by the project leader.
  • Once the patch is accepted, a comitter is in charge to integrate the patch in his local copy to check that the unit tests pass etc, and then commit.

Actual context

Currently, because of the small number of contributors, there is only one reviewer, who is the actual project leader (Laurent).