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 [2008/05/30 21:20]
diraison modification de l'indentation
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 ======
  
-===== Méthodologie ​de 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 ​=====
  
 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 :
-  - faire les modifications proprement ​dites, +  ​- [[devel:​multirepo | récupérer le code source]] 
-  - documenter les modifications (''​dch''​),​ +  - créer une branche locale (''​git checkout -b //​nouvelle_branche//​ //​branche_de_depart//''​) 
-  - construire le paquet ​(''​svn-buildpackage''​), +  ​- faire les modifications proprement ​dites ; 
-  - tester le paquet, +  - 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 ; 
-  - si la modification fonctionne, envoyer (''​debcommit''​) ​la modification dans le dépôt SVN, +  - envoyer (''​debcommit''​) la modification dans le dépôt GIT local ; 
-  - faire d'​autres modifications de la même manière, +  - construire le paquet ​avec ''​git-buildpackage'' ​; 
-  - une fois la nouvelle version du paquet prêtele noter dans le changelog (''​dch -r''​), +  - tester le paquet ; 
-  - construire le paquet (''​svn-buildpackage''​), +  - si la modification fonctionne, ​l'envoyer ​dans le dépôt GIT central ​(''​$ git push …''​) ; 
-  - relire ses modifications (''​debdiff''​) +  - faire d'​autres modifications de la même manière ​(incrémenter le suffixe ''​~//​X//''​ à chaque nouvelle modification substantielle) ;​ 
-  - envoyer le paquet ​dans l'​archive ​(''​dput''​), +  - 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//''​ 
-  - étiquetter la version ​dans le dépôt ​SVN (''​debcommit --release''​).+  - 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''​) ; 
 +  - 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''​). 
 + 
 +Pour avoir un ''​dch''​ correctement configuré il faut mettre les lignes suivantes dans ''​~/​.devscripts''​ :​ 
 +<​file>​ 
 +DEBCHANGE_RELEASE_HEURISTIC=changelog 
 +DEBCHANGE_MULTIMAINT_MERGE=yes 
 +DEBCHANGE_PRESERVE=yes 
 +</​file>​
  
-===== Placement ​et nommage des fichiers binaires =====+Les pages [[devel:​git-buildpackage]] ​et [[devel:​dput]] détaillent l'​usage et la configuration de ces deux outils.
  
-Grace au travail d'​Olivier Lecam, l'​élévation de privilèges pour les scripts lancés par l'​interface web se font via un //wrapper// de sudo, rootexec+===== Placement et nommage des exécutables =====
  
-Les scripts ​binaires peuvent donc être placés dans les répertoires **''/​bin,​ /sbin, /​usr/​bin''​**,​ et **''/​usr/​sbin''​** pour être en conformité avec le  [[http://​www.debian.org/​doc/​packaging-manuals/​fhs/​fhs-2.3.html|debian file hierarchy standart]]+Les scripts ​exécutables doivent ​être placés dans les répertoires **''/​bin,​ /sbin, /​usr/​bin''​**,​ et **''/​usr/​sbin''​** pour être en conformité avec le [[http://​www.debian.org/​doc/​packaging-manuals/​fhs/​fhs-2.3.html|FHS (File Hierarchy Standard)]].
  
-les fichiers binaires, pour éviter toute confusion devraient : +Pour éviter toute confusion, les exécutables ​devraient : 
-  * avoir comme préfixe slis- +  * avoir comme préfixe ​''​slis-''​ 
-  * Si le binaire est destiné à une action uique, être suivie ​de l'action , i.e. test pour un test, mk pour la construction ​d'​un ​fichier +  * respecter les schémas ​de nommage existants:​ 
-  et terminer ​par le service ​concerné.+    * ''slis-test-//​service//'' ​pour un script de test d'​un ​service 
 +    ''​slis-//​service//​-config''​ pour un script de configuration initiale d'un service (qui respecte les conventions d'​appel imposées ​par ''​handle_initial_config''​ de slis-common) 
 +    * ''​slis-mk-//​service//''​ pour un script regénérant la configuration du service
  
-exemple ​+Exemple ​
   * **''/​usr/​bin/​slis-mk-squidconf''​** // binaire qui crée un fichier de conf //   * **''/​usr/​bin/​slis-mk-squidconf''​** // binaire qui crée un fichier de conf //
   * **''/​usr/​bin/​slis-test-squid''​** // binaire qui teste un service //   * **''/​usr/​bin/​slis-test-squid''​** // binaire qui teste un service //
   * **''/​usr/​sbin/​slis-firewall''​** // binaire avec de multiples actions possibles //   * **''/​usr/​sbin/​slis-firewall''​** // binaire avec de multiples actions possibles //
 +
 +===== 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://​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>​
 +: <<​=cut
 +
 +=head1 NAME
 +
 +script - short description of the script
 +
 +=head1 SYNOPSIS
 +
 +B<​script>​ [options] I<​file>​
 +
 +=head1 DESCRIPTION
 +
 +Here's some normal text.  It includes text that is
 +B<​bolded>,​ I<​italicized>,​ U<​underlined>,​ and 
 +C<​$code>​-formatted.
 +
 +=head1 OPTIONS
 +
 +=over 4
 +
 +=item B<​--option1>​
 +
 +Description of the option one.
 +
 +=item B<​--option2>​
 +
 +Another description.
 +
 +=back
 +
 +=head1 SEE ALSO
 +
 +L<​manpage>,​ L<​another-script>​.
 +
 +=head1 AUTHOR
 +
 +J. Random Hacker <​jrh@example.com>​.
 +
 +=cut
 +</​code>​
 +
 +Cet exemple reprend la structure basique nécessaire. Les sections NAME, SYNOPSIS et DESCRIPTION sont standardisées et nécessaires,​ cela permet de générer des pages de manuel correctes et d'​afficher des informations pertinentes en lançant ''​script <​nowiki>​--help</​nowiki>''​.
  
 ===== Guide de style pour le code ===== ===== Guide de style pour le code =====
Ligne 44: Ligne 123:
 } }
  
 +result=0
 while true; do while true; do
     if [ "​$1"​ = "​yes"​ ]; then     if [ "​$1"​ = "​yes"​ ]; then
Ligne 72: Ligne 152:
 } }
  
 +my $result = 0;
 while (1) { while (1) {
     if ($ARGV[1] eq "​yes"​) {     if ($ARGV[1] eq "​yes"​) {
Ligne 84: Ligne 165:
  
 <code php> <code php>
 +<?php
 +function do_something() {
 +    echo "​blabla\n";​
 +}
  
 +$result = 0;
 +while(true) {
 +    if ($_GET["​do"​] == "​yes"​) {
 +        do_something();​
 +    } else {
 +        do_something_else();​
 +    }
 +}
 +?>
 </​code>​ </​code>​
  

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