developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
Proposing a patch
You have to follow this steps, in order to create a patch.
- retrieve the last version of jelix from the repository (and not from the download area !)
- create the ini file for the build script
- modify the sources of jelix in order to fix the bug you want to correct, or to made improvements
- build Jelix and build testapp
- test your changes and launch unit tests in the testapp application
- if not ok, back to the third step.
- all is ok, you can create the patch or commit in your clone on github.
Details about this steps are described here, except the last one. Let's explain it.
The content of your patch
Your patch should contain all the modifications in the code, but it must all contains modifications in the headers of all files you changed: your name, your copyright etc. You should also update the lib/jelix/CREDITS files.
Creating the patch
There are two ways to provide patch, depending of how you work and how you contribute.
You create a tiny patch on a single file
The simplier way for a beginner is to edit the file to change directly on github.
- Go on https://github.com/jelix/jelix/tree/master/
- select the oldest branch on which you want to fix the issue
- Navigate and display the file you want to modify
- Click on the "edit" button
- make your changes
- confirm etc: it will create a pull request for you.
Your changes will then be reviewed by a core developer. He may ask some modifications. When it is ok, your changes will be integrated in the branch you selected, and the core developper will merge it in newer branches.
You are an active contributor or you want to propose a patch that have more one file
If you provide often some patches (unrelated or not), or if you'are familiar with Git, the best way is to "fork" on Github.com. Please create a branch for each modification you want to provide, so we could merge them independently, after the review. As we would like to have a "clear" history, for little modifications, try to create only one commit, not 10 or 20 :-). For complex modifications, it's better of course to have several commit. Try to commit clear steps, in order to have an understandable history. Each changeset should correspond to a specific step of the change.
When your modification is done, push your changes on your github account, and do a "pull request" on github.
Guide lines for commit
Here are some rules to follow for commit.
For contributors having rights access on the repository, they can commit and push directly on the official repository, reviewed patchs and minor modifications (syntax errors, mispelling...).
Every patchs/pull request should be reviewed, before their landing on the official repository.
Of course, changes should not break something: tests should be ok (or adapted to be ok).
Every changes should contain tests if possible.
The message of a commit:
- should be written in english
- it should contain:
- the "Refs #xxx" or "Closes #xxx" where xxx is the number of the issue on github.
- the description of the change
- you must indicate the author of the patch with the -u option if you're not the author
git commit -u "Bob <firstname.lastname@example.org>" -m "Added support of multiline tags in templates. Refs #4444"