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 20 and Version 21 of fr/patchs
- Timestamp:
- Jan 1, 2012, 10:03:36 PM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
fr/patchs
v20 v21 33 33 Il se peut que ce soit un patch incomplet (vous n'avez pas le temps de le finir, vous voulez passer la main, ou alors ce n'est qu'une première étape etc...), dans ce cas là, vous vous arrêtez là. (Toutefois un commentaire ne sera pas de trop pour indiquer le pourquoi, où vous en êtes etc..) 34 34 35 Sinon, si votre patch vous semble prêt, sélectionnez "review?" dans le champs review du ticket. Cela veut dire que vous demandez une review.35 Sinon, si votre patch vous semble prêt, choisissez "ask a review" dans le ticket. Cela veut dire que vous demandez une review. Un "reviewer" regardera alors votre patch, et vous dira en retour si il y a des améliorations à faire ou si c'est bon. Si ce n'est pas bon, il faudra faire les améliorations demandées et proposer un nouveau patch que vous attacherez sur le même ticket. Et vous demanderez alors une nouvelle review. Et ainsi de suite. 36 36 37 Un "reviewer" regardera alors votre patch, et vous dira en retour si il y a des améliorations à faire (il mettra "review-") ou si c'est bon ("review+"). 38 39 Si il y a "review-", il faudra faire les améliorations demandées et proposer un nouveau patch que vous attacherez sur le même ticket. Et vous demanderez alors une nouvelle review ("review?"). Et ainsi de suite. 40 41 Une fois que vous avez "review+", si vous avez les droits pour commiter dans le dépôt mercurial, vous incluez alors vos modifications dans le dépôt. Sinon un "commiter" le fera à votre place. Voir [wiki:fr/subversion les conventions pour commiter]. 37 Une fois que le patch est accepté, si vous avez les droits pour commiter dans le dépôt git, vous incluez alors vos modifications dans le dépôt. Sinon un "commiter" le fera à votre place. Voir [wiki:fr/commits les conventions pour commiter]. 42 38 43 39 44 40 === Vous êtes un contributeur actif === 45 41 46 Si vous fournissez des patch es régulièrement (indépendants ou non), la meilleure façon est de "forker" le depot de jelix dans votre compte github.42 Si vous fournissez des patchs régulièrement (indépendants ou non), la meilleure façon est de "forker" le dépôt de jelix dans votre compte github. 47 43 48 44 Créez une branche dans votre "fork", pour chaque modification distincte (pour chaque ticket en gros). Cela permettra alors de fusionner les branches qui ont été acceptées sans inclure vos modifications non terminées ou refusées. 49 45 50 Pour les petites modifications, essayez de limiter le nombre de commit. Cela sera plus facile de faire la review,et cela permettra de garder un historique clair. Pour les modifications plus conséquentes, il est préférable bien sûr d'avoir plusieurs commits, un pour chaque étape. Afin d'obtenir un historique compréhensible, essayer de faire des commits clairs. Chaque changement devrait correspondre à une étape spécifique de modifications.46 Pour les petites modifications, essayez de limiter le nombre de commit. La review sera plus simple et cela permettra de garder un historique clair. Pour les modifications plus conséquentes, il est préférable bien sûr d'avoir plusieurs commits, un pour chaque étape. Afin d'obtenir un historique compréhensible, essayer de faire des commits clairs. Chaque changement devrait correspondre à une étape spécifique de modifications. 51 47 52 48 Lisez [wiki:fr/commits la page sur les commits] pour le format des messages des commits. 53 49 54 50 55 Quand votre modification est prête, faites un "pull request" sur github. Si il y a un ticket correspondant sur developer.jelix.org, vous pouvez aussi informer sur ce ticket vos travaux . Un reviewer vérifiera alors votre code, proposera peut-être des améliorations à faire, et ensuite importera vos changements dans le dépôt officiel.51 Quand votre modification est prête, faites un "pull request" sur github. Si il y a un ticket correspondant sur developer.jelix.org, vous pouvez aussi informer sur ce ticket vos travaux (en choisissant "ask a review" dans le ticket par exemple). Un reviewer vérifiera alors votre code, proposera peut-être des améliorations à faire, et ensuite importera vos changements dans le dépôt officiel. 56 52 57 53