(Courriels de diversion: <repertorie@anticipees-vouerai.com> <relies@tricherai-ridiculiserai.com> <ressemblerions@jumellerais-epouse.com> <capes@coquettes-trafiquee.com> <cauterisation@mobiliers-defibrer.com> <terminez@peignes-programmais.com> <remplirons@rassasiez-enregistrerait.com> <entierete@dialectique-coloniserons.com> <soupconnee@rurale-periclita.com> <budgetisation@bloques-inspiree.com> )


Bonsoir tout le monde,

On Mon, 8 Dec 2003 15:57:42 +0000 (UTC)
Roger.Mampey@cert.fr ("Roger.Mampey") wrote:
> [...]
> 
> 2/ Le gel dont je parle concerne la version courante (cad sans modifs
> des fichiers de données fournis par Frédéric) et le fait est que je ne
> vais pas faire évoluer cette version alors que j'ai l'intention de
> modifier sérieusement les fichiers. La version courante gelée (pour
> moi) sera sous GPL que je sache et tout le monde pourra se
> l'approprier.

Ne serait-il pas judicieux de créer une branche CVS à partir de la 0.3.1
(avec les nouveaux delta) ayant pour but d'accueillir UNIQUEMENT des
modifications visant à stabiliser à TRES court terme le logiciel. Cette
branche permettrait alors de produire les versions 0.3.2, 0.3.3, etc.

La branche principale/courante (nommée HEAD par CVS) permettrait alors
de faire les développements à plus long termes :- reformatage des
sources,- intégration de autoconf/automake,
- modification des fichiers,
- et tout ce que peuvent nous promettre les prochaines versions.

> [...]
> 
> Le partage des tâches n'a jamais été formalisé mais il est
> relativement clair :
> 
> Phil est responsable de l'intégration de la synthèse (en amont vers
> Emacspeak ou autres, en aval vers Mbrola et pas d'autres) de
> l'évolution des versions, des scripts et de la gestion des options
> (j'en oublie peut-être)
> 
> Je suis responsable de la synthèse proprement dite et du code C.

C'est bon à savoir.

> Evidemment, vu que je suis (presque) seul sur le code C, la
> collaboration avec moi-même se passe assez bien (quoique). Pour
> pouvoir travailler à plusieurs sur ce code, ce qui sera le cas
> j'espère avec la version suivante ("en ce qui me concerne") de
> Llia_Phon, il faut respecter des règles de spécification et
> d'utilisation des sous-programmes ou embryons de bibliothèques faites
> par chacun des développeurs. 
> 
> Et, actuellement, il est clair que ce n'est pas fait. 
> 
> En ce qui concerne les spécifications, il faut tenir compte du fait
> qu'elles ont été faites par Frédéric et pas par nous (et qu'il a fallu
> pour l'essentiel les retrouver à partir du code et d'un article de
> Frédéric). Comme je m'y suis engagé à l'Oxford, je vais compiler ces
> specs dans une doc consultable sur le site CVS. Comme pour le reste,
> je vise fin Janvier.

 Ce sera très pratique pour ne pas faire des "régressions". On pourra
sans doute aussi produire des tests automatiques pour assurer/garantir
le respects de ces spec. (c'est par exemple ce que préconise la méthode
eXtreme Programming, XP de son petit nom).

> En ce qui concerne la doc d'utilisation : fonctionnalité de chaque 
> sous-programme, nature des entrées/sorties et des modifications faites
> sur les données (variables globales ou transmises par pointeur), il
> faudra attendre plus longtemps ou alors un développeur impatient. De
> toutes façons, il faut attendre que l'opération de nettoyage du code
> soit terminée.

Pour faire ce genre de documentation, l'utilitaire doxygen est
extrêmement utile : on met les informations directement dans le source,
plus précisément dans les commentaires, en respectant un certain
formalisme et l'outil génère :- un site HTML pour consultation en ligne,
- une doc imprimable,
- etc.

Je vais faire tourner doxygen sur LLiaPhon dans l'état actuel et je
publierai le résultat sur mon site perso.  Vous pourrez ainsi vous faire
une idée de l'utilité.

A++,
-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 -=- JID: guyou@jabber.org guyou@amessage.be-= mailto:guilhem.bonnefille@laposte.netmailto:guilhem.bonnefille@free.fr-= http://nathguil.free.fr/http://home.tele2.fr/nathguil/