wiki:en/patches
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 6 (modified by laurentj, 9 years ago) (diff)

--

Proposing a patch

You have to follow this steps, in order to create a patch.

  1. retrieve the last version of jelix from the repository (and not from the download area !)
  2. create the ini file for the build script
  3. modify the sources of jelix in order to fix the bug you want to correct, or to made improvements
  4. build Jelix and build testapp
  5. test your changes and launch unit tests in the testapp application
  6. if not ok, back to the third step.
  7. 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 3 ways to provide patch, depending of how you work and how you contribute.

You create occasionnaly a patch

The simplier way is to use "git diff". In the directory of your local copy of the repository, you should have made all your changes. When your changes are ok, just type:

git diff > mypatch.diff

Then you have a mypatch.diff file.

If your modification has to be applied on stable branches, create the patch with the oldest branch.

Submit the patch into a ticket on developer.jelix.org. The ticket can be an existing one, or perhaps you have to create it. Create/edit the ticket and attached the file. Then you have to request a review. You should ask a review by setting the "review" field of the ticket to "review?". Then a reviewer will verify your patch. If it is ok, he will set "review+". If your patch needs some improvements, he will set "review-" and then you will have to make improvements he asked and you will create a new patch, submit it on the ticket, ask "review?" and so on. When you have "review+", you can commit the patch in the repository if you have write acces, or a "commiter" will do it for you.

You are an active contributor

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.

Conditions

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.

Commit message

The message of a commit:

  • should be written in english
  • it should contain:
    • the "ticket #xxx" where xxx is the number of a ticket on developer.jelix.org.
    • the description of the change
    • the reviewer name: "r=bob"
  • you must indicate the author of the patch with the -u option if you're not the author

Example:

git commit -u "Bob <bob@example.local>" -m "ticket #68987: added support of multiline tags in templates. r=laurent"

summary