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

Version 3 (modified by laurentj, 12 years ago) (diff)


The development process

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


On the Jelix project, we follow a process of "peer-reviewing". Each modifications should be submit in a ticket, and an other developer will review your code before to include it into the repository of Jelix.

How does it happens:

  • a contributor propose a bug fix or an improvement by creating a patch. He attach this patch to a ticket in the bug tracker.
  • a reviewer reads the code of the patch, and verifies that the quality is good, the coding style is good, and the patch does things well.
  • all new features are also reviewed by one of the core developers.
  • when the patch is ok, the patch is commited in the repository, by the contributor if he has write access on the repository, or by an other developer.
  • each days, nightlies of jelix are built and are available in the download area ( And at the same time, all unit tests are executed and the result of this unit tests are mailed to the jelix-dev mailing list.

Unit tests

Somte unit tests should be provided with each new features or bug fixed. It allow to verify that the framework is still working well, and to verify that there isn't any regressions.

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 regular 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).