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.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
Changes between Version 7 and Version 8 of en/patches
- Timestamp:
- Jun 16, 2014, 10:47:45 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
en/patches
v7 v8 21 21 == Creating the patch == 22 22 23 There are 3ways to provide patch, depending of how you work and how you contribute.23 There are two ways to provide patch, depending of how you work and how you contribute. 24 24 25 === You create occasionnaly a patch===25 === You create a tiny patch on a single file === 26 26 27 The simplier way for a beginner 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:27 The simplier way for a beginner is to edit the file to change directly on github. 28 28 29 git diff > mypatch.diff 29 * Go on https://github.com/jelix/jelix/tree/master/ 30 * select the oldest branch on which you want to fix the issue 31 * Navigate and display the file you want to modify 32 * Click on the "edit" button 33 * make your changes 34 * confirm etc: it will create a pull request for you. 30 35 31 Then you have a mypatch.diff file.36 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. 32 37 33 If your modification has to be applied on stable branches, create the patch with the oldest branch.34 38 35 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. Choose "ask a review" on the ticket. Then a reviewer will verify your patch. If it is ok, the ticket will be "reviewed". If your patch needs some improvements, it will be "assigned" again and the reviewer will ask to make some improvements. Then create a new patch, submit it on the ticket, "ask a review" again and so on. When it is ok, you can commit the patch in the repository if you have write acces, or a "commiter" will do it for you. 36 37 === You are an active contributor === 39 === You are an active contributor or you want to propose a patch that have more one file === 38 40 39 41 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. … … 64 66 * should be written in english 65 67 * it should contain: 66 - the " ticket #xxx" where xxx is the number of a ticket on developer.jelix.org.68 - the "Refs #xxx" or "Closes #xxx" where xxx is the number of the issue on github. 67 69 - the description of the change 68 - the reviewer name: "r=bob"69 70 * you must indicate the author of the patch with the -u option if you're not the author 70 71 71 72 Example: 72 73 {{{ 73 git commit -u "Bob <bob@example.local>" -m "ticket #68987 - added support of multiline tags in templates. r=laurent" 74 git commit -u "Bob <bob@example.local>" -m "Added support of multiline tags in templates. 75 76 Refs #4444" 74 77 }}} 75 78