Vous êtes sur le wiki de développement du projet SLIS

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Both sides previous revision Révision précédente
Prochaine révision
Révision précédente
devel:conventions [2009/11/10 17:49]
rhertzog
devel:conventions [2013/05/30 16:26] (Version actuelle)
fernando [Procédure de modification d'un paquet] màj de la procédure (merge avant release)
Ligne 1: Ligne 1:
 ====== Conventions pour le développement ====== ====== Conventions pour le développement ======
 +
 +===== Conventions sur les branches et les tags =====
 +
 +Les branches LCS:
 +  * origin/​master : la version déployée modifiée pour SLIS.
 +  * <​nom_developpeur>/​*:​ des branches de travail personnelles
 +  * upstream/*: le paquet fourni par LCS, avec les branches et tags SVN (importés automatiquement par git-svn)
 +
 +Les branches SLIS:
 +  * origin/4.1 : la version déployée
 +  * origin/​master : la version en cours de développement
 +  * <​nom_developpeur>/​*:​ des branches de travail personnelles
 +
 +Les branches personnelles doivent être supprimées une fois qu'​elles ont été fusionnées dans la branche master.
 +
 +Les tags sont simplement les numéros de version des paquets lorsqu'​ils sont publiés. Les tags des versions publiées doivent pointer sur un commit de la branche master ou 4.1. Les tags des versions publiées par LCS doivent pointer sur un commit de la branche upstream.
 +
  
 ===== Procédure de modification d'un paquet ===== ===== Procédure de modification d'un paquet =====
  
 Voici les étapes que l'on fait habituellement lorsqu'​on fait une modification dans un paquet pour SLIS : Voici les étapes que l'on fait habituellement lorsqu'​on fait une modification dans un paquet pour SLIS :
 +  - [[devel:​multirepo | récupérer le code source]]
 +  - créer une branche locale (''​git checkout -b //​nouvelle_branche//​ //​branche_de_depart//''​)
   - faire les modifications proprement dites ;   - faire les modifications proprement dites ;
   - documenter les modifications (''​dch''​),​ cela créera une nouvelle version automatiquement si ''​dch''​ est correctement configuré (voir ci-dessous),​ il convient d'​ajouter un suffixe ''​~1''​ à la version dans ce cas pour indiquer qu'il s'agit encore d'une préversion à ce stade ;   - documenter les modifications (''​dch''​),​ cela créera une nouvelle version automatiquement si ''​dch''​ est correctement configuré (voir ci-dessous),​ il convient d'​ajouter un suffixe ''​~1''​ à la version dans ce cas pour indiquer qu'il s'agit encore d'une préversion à ce stade ;
-  - construire le paquet ​(''​svn-buildpackage ​-us -uc <​nowiki>​--svn-ignore</​nowiki>​''​;+  ​- envoyer (''​debcommit''​) la modification dans le dépôt GIT local ; 
 +  ​- construire le paquet ​avec ''​git-buildpackage''​ ;
   - tester le paquet ;   - tester le paquet ;
-  - si la modification fonctionne, envoyer (''​debcommit''​) ​la modification dans le dépôt SVN ;+  - si la modification fonctionne, ​l'envoyer ​dans le dépôt GIT central ​(''​$ git push …''​) ;​
   - faire d'​autres modifications de la même manière (incrémenter le suffixe ''​~//​X//''​ à chaque nouvelle modification substantielle) ;​   - faire d'​autres modifications de la même manière (incrémenter le suffixe ''​~//​X//''​ à chaque nouvelle modification substantielle) ;​
-  - une fois la nouvelle version du paquet prêtele noter dans le changelog (''​dch -r''​) ;​ +  - quand les modifications sont prêtes à être publiéesfusionner avec la branche de départ (''​$ git checkout //​branche_de_depart//''​ puis ''​$ git merge --no-ff //​nouvelle_branche//''​ 
-  - construire le paquet (''​svn-buildpackage <​nowiki>​--svn-tag</​nowiki>''​) ;​+  - noter dans le changelog ​la nouvelle version, sans ''​~//​X//''​ en fin de version ​(''​dch -r''​) ;​ 
 +  - construire le paquet (''​git-buildpackage <​nowiki>​--git-tag</​nowiki>''​) ;​
   - relire ses modifications (''​debdiff''​) ;​   - relire ses modifications (''​debdiff''​) ;​
 +  - envoyer le tag dans le dépôt GIT central (''​$ git push --tags …''​) ;
 +  - envoyer les modifications dans dépôt GIT central ''​$ git push …''​) ;
   - envoyer le paquet dans l'​archive (''​dput''​).   - envoyer le paquet dans l'​archive (''​dput''​).
  
Ligne 22: Ligne 45:
 </​file>​ </​file>​
  
-Les pages [[devel:svn-buildpackage]] et [[devel:​dput]] détaillent l'​usage et la configuration de ces deux outils.+Les pages [[devel:git-buildpackage]] et [[devel:​dput]] détaillent l'​usage et la configuration de ces deux outils.
  
 ===== Placement et nommage des exécutables ===== ===== Placement et nommage des exécutables =====
Ligne 42: Ligne 65:
 ===== Documentation des scripts ===== ===== Documentation des scripts =====
  
-Tous les scripts shell et Perl doivent être documentés avec du POD ([[http://​en.wikipedia.org/​wiki/​Plain_Old_Documentation|Plain Old Documentation]]). Ce POD est ensuite exploité par ''​pod2man''​ pour générer la page de manuel correspondante. L'​interpréteur perl sait ignorer le POD de manière native mais ce n'est pas le cas des interpréteurs shell. Il faut donc exploiter [[http://​alma.ch/​blogs/​bahut/​2007/​08/​embedding-documentation-in-shell-script.html|une petite astuce]] pour pouvoir intégrer du POD n'​importe où dans un tel script :+Tous les scripts shell et Perl doivent être documentés avec du POD ([[http://​en.wikipedia.org/​wiki/​Plain_Old_Documentation|Plain Old Documentation]]). Ce POD est ensuite exploité par ''​pod2man''​ pour générer la page de manuel correspondante. L'​interpréteur perl sait ignorer le POD de manière native mais ce n'est pas le cas des interpréteurs shell. Il faut donc exploiter [[http://bahut.alma.ch/​2007/​08/​embedding-documentation-in-shell-script_16.html|une petite astuce]] pour pouvoir intégrer du POD n'​importe où dans un tel script :
  
 <​code>​ <​code>​
Ligne 53: Ligne 76:
 =head1 SYNOPSIS =head1 SYNOPSIS
  
-    ​script [options] <​file>​+B<script[options] ​I<​file>​
  
 =head1 DESCRIPTION =head1 DESCRIPTION

QR Code
QR Code devel:conventions (generated for current page)