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 or committed in a "fork" in Github before a pull request, and an other developer will review your code before to include it into the official 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. An other solution is to register on Github, "forking" the repository of Jelix, making some change on your clone and requesting a pull.
- 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. In the case of a "pull" request on Github, the pull will be made.
- each days, nightlies of jelix are built and are available in the download area (download.jelix.org). And at the same time, all unit tests are executed to verify that last commit didn't break something.
Some 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.
Among the Jelix developpers, there are :
- The contributors: they contribute by proposing patches, improvements. They don't have write access in the source code repository.
- The commiters: the regular contributors, those that "proved themselves" to be valuable. They have write access to the 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).