(Courriels de diversion: <trafiquee@cauterisation-mobiliers.com> <defibrer@terminez-peignes.com> <programmais@remplirons-rassasiez.com> <enregistrerait@entierete-dialectique.com> <coloniserons@soupconnee-rurale.com> <periclita@budgetisation-bloques.com> <inspiree@annexees-avilis.com> <depose@encrant-secretait.com> <ambree@reexaminant-regretteriez.com> <fusionniez@gauchi-ravisse.com> )


Bonjour,

Comme Phil doit s'en douter, la façon dont le débat est parti sur le "partage 
des tâches" ne me convient pas du tout.

Tout d'abord, from Phil :

> (... sachant que Roger a parlé d'un gel des évolutions de LLiaPhon mais ça se 
> discute aussi).

1/ Mon mail commence par "en ce qui me concerne"

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.

Ensuite, toujours from Phil :

> Franz, es-tu volontaire pour initier ces pages sous CVS (répertoire BigWeb, a
> priori) de :
> - règles de codage et leur instrumentation

Qunad on intervient à plusieurs sur le même code, il y a une règle impérative 
qui s'applique selon moi :

Chaque développeur est responsable d'une partie du code (dont les scripts de 
compilation et d'installation) : ça peut être une fonctionnalité ou un fichier, 
voire un sous-programme si le nombre de développeurs devient phénoménal, mais 
pas en dessous. Et quand un développeur écrit un sous-programme, personne ne 
repasse derrière pour modifier quoi que ce soit sans accord préalable du 
responsable.

Il y a déjà eu des frictions entre Phil et moi (j'ai fini par tolérer les 
'assert' qu'il me fourre partout parce qu'il ont une fonction de 
"certification", mais quand je parle de nettoyage du code, je pense aussi à 
eux). Je ne vous dis pas ce que je pense de la proposition de Franz de modifier 
l'indentation ou la façon dont sont placés les commentaires ou encore d'imposer 
une règle là-dessus à tout développeur. Comme dit Guilhem, il y a 'indent' (je 
ne connais pas 'cb' non plus) qui peut fournir n'importe quel mode "standard" de 
présentation (mais pas celui qui me va bien, évidemment).

Evidemment, il y des aménagements avec cette règle et on peut envisager la 
corresponsabilité (à 2 ou 3 mais certainement pas davantage) sur certaines 
fonctionnalités encore mal dégrossies ou certains fichiers un peu fourre-tout.
C'est par exemple le cas des fichiers synthese.c et util.c (.h) où nous sommes, 
de fait, Phil et moi corresponsables.

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.

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.

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.

	Roger