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.

Changes between Version 7 and Version 8 of en/patches


Ignore:
Timestamp:
Jun 16, 2014, 10:47:45 PM (6 years ago)
Author:
laurentj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • en/patches

    v7 v8  
    2121== Creating the patch ==
    2222
    23 There are 3 ways to provide patch, depending of how you work and how you contribute.
     23There are two ways to provide patch, depending of how you work and how you contribute.
    2424
    25 === You create occasionnaly a patch ===
     25=== You create a tiny patch on a single file ===
    2626
    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:
     27The simplier way for a beginner is to edit the file to change directly on github.
    2828
    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.
    3035
    31 Then you have a mypatch.diff file.
     36Your 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.
    3237
    33 If your modification has to be applied on stable branches, create the patch with the oldest branch.
    3438
    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 ===
    3840
    3941If 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.
     
    6466 * should be written in english
    6567 * 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.
    6769    - the description of the change
    68     - the reviewer name: "r=bob"
    6970 * you must indicate the author of the patch with the -u option if you're not the author
    7071
    7172Example:
    7273{{{
    73 git commit -u "Bob <bob@example.local>" -m "ticket #68987 - added support of multiline tags in templates. r=laurent"
     74git commit -u "Bob <bob@example.local>" -m "Added support of multiline tags in templates.
     75
     76Refs #4444"
    7477}}}
    7578