website view fr/devel/forge.php @ rev 1021

fr: utf-8
author Paul Issott <paul@slitaz.org>
date Sat Mar 31 16:55:59 2012 +0100 (2012-03-31)
parents 175ff0253b7a
children e0ee682de0a0
line source
1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
4 <head>
5 <title>SliTaz (fr) - Forge</title>
6 <meta http-equiv="content-type" content="text/html; charset=utf-8" />
7 <meta name="description" content="Développement de SliTaz GNU/Linux" />
8 <meta name="keywords" lang="fr" content="developpement slitaz developer GNU Linux" />
9 <meta name="author" content="Christophe Lincoln"/>
10 <?php include("../../lib/html/meta-link.html"); ?>
11 </head>
12 <body>
14 <?php include("../../lib/html/header.html"); ?>
16 <!-- Block -->
17 <div id="block">
18 <?php include("../../lib/html/nav.fr.html"); ?>
19 <!-- Information/image -->
20 <div id="block_info">
21 <h4>Forge</h4>
22 <p>
23 Les outils et services utilisés pour forger Slitaz :-)
24 </p>
25 <p>
26 <img src="../../images/users.png" alt="users.png" />
27 <a href="http://scn.slitaz.org/">Rejoingez nous sur SCN</a>
28 et la <a href="../mailing-list.php">mailing list</a>
29 </p>
30 </div>
31 </div>
33 <!-- Content -->
34 <div id="content">
36 <h2>Gestion collaborative du développement</h2>
38 <ul>
39 <li><a href="#kiss">KISS et respect des standards.</a></li>
40 <li><a href="#tank">Build host &amp; home.</a></li>
41 <li><a href="#repos">Dépôts Mercurial.</a></li>
42 <li><a href="#iconv">Implémentation d'iconv().</a></li>
43 <li><a href="#pkgs">Paquets tazpkg.</a></li>
44 <li><a href="#pkgs-naming">Nommage des paquets.</a></li>
45 <li><a href="#site">Gestion du site Web et des livres.</a></li>
46 <li><a href="#xhtml">xHTML coding style.</a></li>
47 </ul>
49 <p>
50 Le projet SliTaz dispose de divers moyens pour gérer le travail des
51 développeurs et collaborer. Un système de gestion de révision avec Mercurial
52 (Hg), des modules de synchronisation avec Rsync, de la documentation, une
53 <a href="../mailing-list.php">liste de discussion</a> et un canal IRC. Tous
54 les développeurs sont inscrits sur la liste, c'est le moyen de collaboration
55 principal et privilégié.
56 </p>
58 <a name="kiss"></a>
59 <h3>KISS et respect des standards</h3>
60 <p>
61 Rester simple, respecter au mieux les standards, réaliser un travail soigné,
62 rédiger de la documentation de haute qualité, fournir un système stable et
63 robuste et garder le <em>rootfs</em> du LiveCD standard assez léger pour que
64 SliTaz tourne sur des machines ayant au minimum 128 Mb de RAM. Possibilité
65 d'utiliser GTK+2, Dialog, Gtkdialog, des scripts SHell ou encore PHP pour
66 coder des outils propres à la distribution. L'idée est aussi de ne pas faire
67 de doublons et de penser mini...
68 </p>
69 <p>
70 SliTaz se veut un projet proche et à l'écoute des ses utilisateurs. Il y a
71 plusieurs développeurs actifs sur le <a href="http://forum.slitaz.org/">forum</a>
72 et sur la <a href="../mailing-list.php">liste de discussion</a>.
73 </p>
75 <a name="tank"></a>
76 <h3>Tank - Build host &amp; home</h3>
77 <p>
78 Chaque contributeur peut avoir un compte sur le serveur principal du
79 projet, avec un accès sécurisé, de l'espace disque, un répertoire public
80 et tous les outils de développement. Les développeurs peuvent y compiler
81 leurs paquets et les mainteneurs du miroir s'occupent de la synchronisation.
82 Tank héberge aussi le site internet, le web boot et les dépôts Mercurial:
83 <a href="http://tank.slitaz.org/">tank.slitaz.org</a>
84 </p>
85 <p>
86 L'utilisation du build host est décrite dans le Cookbook:
87 <a href="http://doc.slitaz.org/en:cookbook:buildhost">SliTaz Build Host (tank)</a>.
88 </p>
90 <a name="repos"></a>
91 <h3>Dépôts Mercurial</h3>
92 <p>
93 Tous les sous-projets tels que Tazpkg, Tazwok ou Tazlito ont leurs propres
94 dépôts Hg sur le serveur du projet, tout comme le wok. Les développeurs ont
95 un compte et des droits en écriture afin de pouvoir envoyer leurs recettes,
96 mises à jour ou modifications. Il est bien sûr possible de demander la création
97 d'un nouveau dépôt pour collaborer sur un nouveau sous-projet lié à SliTaz.
98 A noter qu'il y a 2 domaines : <a href="http://hg.slitaz.org/">hg.slitaz.org</a>
99 est public et <code>repos.slitaz.org</code> nécessite une authentification, c'est-à-dire
100 que vous pouvez cloner hg.slitaz.org mais pas y pousser vos changements ou fichiers.
101 </p>
102 <h4>~/.hgrc</h4>
103 <p>
104 Mercurial utilise un fichier caché <code>~./hgrc</code> permettant de
105 spécifier son nom d'utilisateur. Il faut mettre votre nom et adresse mail pour
106 qu'on sache qui a modifié quoi. Et attention à ne pas être <em>root</em> pour
107 pousser vos modifications. Exemple :
108 </p>
109 <pre class="script">
110 [ui]
111 username = Prénom Nom &lt;you@example.org&gt;
112 </pre>
113 <h4>Cloner, modifier, commiter et pousser</h4>
114 <p>
115 Vous avez le choix de cloner anonymement via hg.slitaz.org ou directement avec
116 votre login et mot de passe. Pour cloner un dépôt tel que le wok :
117 </p>
118 <pre>
119 $ hg clone http://repos.slitaz.org/wok/
120 </pre>
121 <p>
122 Copier, créer, modifier des recettes ou des fichiers dans <code>stuff</code>.
123 Avant de pouvoir pousser vos modifs, il faut les additionner à votre dépôt
124 local et les commiter. A noter que la commande <code>status</code> permet de
125 savoir quels fichiers ont été modifiés :
126 </p>
127 <pre>
128 $ cd wok
129 $ hg status
130 $ hg add
131 $ hg commit
132 </pre>
133 <p>
134 La commande <code>commit</code> va ouvrir l'éditeur de texte Nano pour écrire le message
135 destiné aux logs (Ctrl + X pour enregistrer et quitter). Vous pouvez éviter
136 Nano en utilisant l'option : <code>-m "Message"</code>. And please,
137 messages in English if possible :
138 </p>
139 <pre>
140 $ hg commit -m "Message for Mercurial log"
141 </pre>
142 <p>
143 Une fois que tout est prêt, vous pouvez encore utiliser la commande
144 <code>log</code> pour voir ce qui va être affiché sur l'interface web. Pour
145 pousser vos changements c'est <code>push</code> :
146 </p>
147 <pre>
148 $ hg log
149 $ hg push
150 </pre>
151 <p>
152 Si vous avez cloné depuis hg.slitaz.org, il faut alors pousser en spécifiant
153 le bon URL :
154 </p>
155 <pre>
156 $ hg push http://repos.slitaz.org/wok/
157 </pre>
158 <h4>Mettre à jour un wok local</h4>
159 <p>
160 Pour mettre à jour votre wok local avec celui du serveur (<em>pull</em> pour
161 tirer les changements) :
162 </p>
163 <pre>
164 $ hg pull
165 $ hg update
166 </pre>
167 <h4>Commandes utiles</h4>
168 <p>
169 Des commandes hg qui peuvent servir.
170 </p>
171 <ul>
172 <li><code>hg help</code> : affiche la liste complète des commandes.</li>
173 <li><code>hg rollback</code> : annule la dernière action exécutée (commit,
174 pull, push).</li>
175 <li><code>hg log &lt;paquet&gt;</code> : affiche les logs pour un paquet.</li>
176 <li><code>hg head</code> : affiche le dernier log.</li>
177 </ul>
179 <a name="iconv"></a>
180 <h3>Implémentation d'iconv()</h3>
181 <p>
182 SliTaz utilise iconv() fourni par la GNU glibc, même si certain paquets
183 proposent d'utiliser <code>libiconv</code> il faut utiliser la version de
184 la glibc (paquet <code>glibc-locale</code>). Il n'y a donc pas de paquet
185 libiconv (1,2 Mb) dans SliTaz.
186 </p>
188 <a name="pkgs"></a>
189 <h3>Paquets tazpkg</h3>
190 <p>
191 Les paquets tazpkg de SliTaz sont créés automatiquement via Tazwok et les
192 recettes contenues dans le wok, <a href="http://doc.slitaz.org/fr:cookbook:start">le Cookbook</a>
193 décrit <a href="http://doc.slitaz.org/fr:cookbook:wok">l'utilisation des outils SliTaz</a>
194 et le format des <a href="http://doc.slitaz.org/fr:cookbook:receipt">recettes</a>,
195 c'est sans doute par un petit peu de lecture qu'il faut commencer.
196 </p>
197 <p>
198 Concernant le choix des paquets, l'idée est de proposer un paquet par tâche ou
199 fonctionnalité, c'est à dire pas (trop) de doublons et de trouver
200 l'application la plus légère dans son domaine. A noter que les paquets actuels
201 ne sont pas figés, si vous trouvez une alternative à un paquet existant, étant
202 plus légère, ayant plus de fonctionnalités ou étant plus <em>sexy</em> pour
203 quelques Ko supplémentaires, vous pouvez la proposer sur la liste. Une
204 attention particulière est portée aux paquets destinés au LiveCD : strip,
205 suppression de tout ce qui est inutile, dépendances et options de compilation.
206 En général, les paquets candidats pour le corps du LiveCD sont discutés sur
207 la liste.
208 </p>
209 <p>
210 Avant de commencer à compiler et créer des paquets pour SliTaz, assurez-vous
211 qu'une recette n'existe pas dans le wok undigest, disponible sur le miroir
212 principal de SliTaz. N'oubliez pas non plus que les membres de la liste sont
213 là pour vous aider et que pour bien commencer, <a href="http://doc.slitaz.org/fr:cookbook:wok"
214 >la documentation du wok et des outils</a> existe.
215 </p>
217 <a name="pkgs-naming"></a>
218 <h3>Nommage des paquets</h3>
219 <p>
220 Dans la majorité des cas le nom du paquet est celui des sources exception
221 faite des modules Python, Perl, PHP, Ruby, Lua. Par example le paquet Kid
222 fournissant un système de template XML et écrit en Python se nomme:
223 <code>python-kid</code>.
224 </p>
226 <a name="site"></a>
227 <h3>Gestion du site Web et des livres</h3>
228 <p>
229 La gestion du site et des livres (Handbook et Cookbook) est faite via un
230 dépôt Mercurial, ce qui nous permet de traviller à plusieurs. Il faut
231 juste installer <code>mercurail</code> sur SliTaz et connaître les commandes
232 de base. Une fois le dépôt cloné vous avez une copie complète du site en
233 local pour commencer à travailler. Pour cloner le site web :
234 </p>
235 <pre>
236 $ hg clone http://hg.slitaz.org/website
237 </pre>
238 <p>
239 Si vous avez les droits :
240 </p>
241 <pre>
242 $ hg clone http://repos.slitaz.org/website
243 </pre>
244 <p>
245 Sur SliTaz vous pouvez installer le serveur web Lighttpd et mettre le
246 site dans votre répertoire ~/Public, cela permet de naviguer dans votre
247 copie locale via localhost/~user.
248 </p>
250 <a name="xhtml"></a>
251 <h3>xHTML coding style</h3>
252 <p>
253 Les pages du site et des différents <em>books</em> sont codés en xHTML 1.0
254 Transitional, les couleurs pour le <code>body</code> et les titres sont
255 directement mis dans la page, cela permet d'avoir une présentation plus soignée
256 pour Links. Le titre de niveau 1 est utilisé une seule fois en haut de page,
257 le titre 2 correspond au titre du document et les titres de niveau 3 et 4 sont
258 ensuite utilisés pour les sous-titres. Si il y a lieu d'avoir une liste à puces
259 avec des ancres, elle se met en haut juste après le titre de niveau 2. Les
260 paragraphes sont contenus dans les balises <code>&lt;p&gt;&lt;/p&gt;</code>.
261 Pour indenter, nous utilisons des tabulations, elles ont une raison d'être
262 sémantique et prennent moins de place en terme d'octets. Pour mettre
263 du code tel que le nom d'une commande dans un paragraphe, la balise
264 <code>&lt;code&gt;</code> est recommandée. Pour afficher une ou des commandes
265 à lancer dans un terminal, les pages du site utilisent la balise
266 <code>&lt;pre&gt;</code> permettant d'afficher du texte préformaté. Exemple :
267 </p>
268 <pre>
269 $ command
270 </pre>
271 <p>
272 Pour afficher du texte à copier/coller tels que des scripts, des bouts de
273 code, des exemples de fichiers de configuration, etc, c'est aussi la balise
274 <code>&lt;pre&gt;</code> mais avec une classe CSS nommée "script". Exemple:
275 </p>
276 <pre class="script">
277 &lt;pre class="script"&gt;
279 code...
281 &lt;/pre&gt;
282 </pre>
283 <p>
284 Les mots en <em>English</em> se mettent dans la balise <code>&lt;em&gt;</code>
285 et les liens internes sont relatifs. Penser à vérifier la validité du code via
286 le <em>validator</em> en ligne du W3C.
287 </p>
289 <h3>Diff et patch</h3>
290 <p>
291 Les utilitaires <code>diff</code> et <code>patch</code> sont des outils en
292 ligne de commande permettant de créer et d'appliquer un fichier contenant
293 les différences entre deux fichiers. Cette technique est souvent utilisée
294 pour collaborer et permet d'extraire clairement les modifications apportées
295 au fichier original. Pour créer un fichier <code>diff</code> lisible par
296 les humains dans un simple éditeur de texte, il faut utiliser l'option
297 <code>-u</code> en argument :
298 </p>
299 <pre>
300 $ diff -u file.orig file.new > file.diff
301 </pre>
302 <p>
303 Pour appliquer un patch :
304 </p>
305 <pre>
306 $ patch file.orig file.diff
307 </pre>
309 <!-- End of content -->
310 </div>
312 <?php include("../../lib/html/footer.html"); ?>
314 </body>
315 </html>