[AlternC-dev] Maintenance

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Olivier HUET o.huet at apogea.net
Ven 24 Fév 10:33:14 CET 2006


J'appuie totallement la demarche de larpoux.

Moi aussi j'aimerai qu'on distingue une version ou ne fasse que de la 
correction de bugs et une version qu'on "ameliore" autrement qu'en faisant 
juste de la correction de bug.
Un version "maintain" et une version "alpha" serait une bonne chose.


Par contre, sur l'histoire du commit qui "ne marchait pas du tout", la je 
ne suis pas d'accord ! ;-)
Il manquait des elements a Yves, et sans pretendre que ce soit parfait 
(Yves ne sera pas le seul a ne pas comprendre, il faudrait que ce soit 
explique quelque part) c'est deja beaucoup mieux que ce qu'il y avait 
avant... (qui ne permettait rien de faire)
Pour rappel le commit en question ne fait que rajouter un "?server=2" qui 
manquait dans une url, pour que phpMyAdmin demande un login/pass plutot que 
de s'acharner a utiliser www-data qui n'a droit a rien.

-----Message d'origine-----
De:	larpoux [SMTP:larp at cnt-f.org]
Date:	vendredi 24 fevrier 2006 08:35
A:	Liste de Developpement de nouvelles foncti onnalites pour AlternC
Objet:	[AlternC-dev] Maintenance

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The Anarcat a ecrit :

|
| Ce que tu demandes, en bref, c'est un "fork" entre une version
| stable et de developpement.
|
| Je ne crois pas qu'il y ait suffisamment d'energie dans l'equipe
| pour faire une telle maintenance.

Salux a toux,

Je repond avec deux semaines de retard a ce post tellement il m'a
estomaque.
Cette reponse est reellement pour faire avancer le navire et pas du
tout une manifestation d'une attitude negative.

Apres bientot 40 ans d'experience de programmeur/chef de projet c'est
la premiere fois que je rencontre
un projet qui a la pretention de pouvoir exister sans maintenance.

Nous avons installe il y a un an la version 0.9.3 et nouvs avons
evidemment rencontre un nombre certain de bugs.
Chque fois que j'ai voulu m'adresser a l'equipe de developpement les
reponses etaient de deux type (du moins quand il y avait reponse :-~)
- - Ce bug est bien connu est il est corrige dans la prochaine version 
(CVS)
- - Encore pire : il est connu et a ete fixe sur le site de Globenet
(mais il n'est pas dans CVS)

Puis sortie de la version 0.9.3.1. Nous l'avons intalle afin de
beneficier des differents "fixs" effectues.
Du coup on se retrouve maintenant avec un certain nombre de bugs
corriges, plus un nombre probablement equivalent (voir plus)
de bugs introduits par des developements divers (notamment
l'authentification dans le MTA)

Les nouveaux bugs vont etre corriges dans la version suivante (0.9.4
ou 1.0) dans un temps X (plusieurs mois s'il faut repasser tous les
tests de non-regression)
et probablement qu'en meme temps on va rajouter plein de nouveaux bugs
qui vont avoir avec par exemple :
- - le passage de PHP4 a PHP5
- - le passage de apache a apach2
- - l'utilisation de XML pour gerer le bureau,
- - ...

Resultat alternc reste en permanence avec :
- - des bugs connus mais non corriges pendant un temps important
- - des nouveaux bugs qui sont introduit chaque fois qu'on veut
beneficier d'un peu de maintenance

La question n'est pas de savoir si ca coute de l'energie pour faire de
la maintenance, mais de comprendre qu'un projet
sans maintenance ne poura jamais exister.
Si la communaute Alternc pense qu'il n'est *pas* possible de faire a
la fois des developpements et de la maintenance
la *SEULE* conclusion possible est de dire qu'on ne peut plus faire de
developpements.

Mais je voudrais mettre un bemol au post d'Anarcat :
j'ai passe un temps tres important dans ma vie a faire de la maintenance.
Mon experience est qu'il faut quelque fois plusieurs jours (voir
plusieurs semaines) pour comprendre un bug.
Mais que la correction du bug est souvent triviale. Ca ne pose en
general pas une charge enorme de reporter le fix dans deux versions,
(voir quelque fois 3 version) :
- - la version "maintain"
- - la version "alpha"
(la version "beta")

La qualite d'un fix dans une version "maintain" ne se mesure en
general pas de la meme facon que dans une version "alpha". Un patch
est de bonne qualite dans une version '"maintain" :
- - Quand il corrige un vrai probleme
- - S'il modifie un nombre le plus faible possible de lignes.

C'est un probleme statistique : un programmeur normal introduit en
moyenne 1 bug pour 10 lignes de code.
Un patch qui fait moins de 10 lignes a de forte chance de s'approcher
d'une meilleur qualite.
Un patch qui fait intervenir 20 lignes a de bonne chance d'introduire
deux nouveaux problemes en en corrigeant qu'un seul.

Dans 90% des cas au minimum, une correction peut etre appliquee d'une
maniere identique dans une version alpha et dans une version "maintain".
Quelque fois, il faut revoir le design dans la version de
developpement pour corriger un nid de problemes.
Dans ce cas, il ne faut evidemment pas revoir le design dans la
version maintain : il faut coute que coute appliquer quelques patchs
verrue, et vivre avec jusqu'a
la validation et la sortie de la nouvelle version.

Sur un autre sujet, un peu similaire, j'ai constate hier avec un peu
d'inquietude
- - qu'un bug a ete mis en evidence au niveau de l'interface avec 
phpmyadmin
- - un commit dans alternc a ete fait rapidement
- - un autre camarade a constate que ca ne marchait pas du tout

Peut etre acceptable sur une version alpha (qui va passer normalement
ensuite l'etape de Quality Control) mais totalement inacceptable sur
une version "maintain"
qui elle ne peut pas repasser en permanence tous les tests de
non-regression

Je suis certain que le projet Alternc a les moyens d'avoir une
methodologie de developpement conforme a quelques principes basics
absoluement pas negociable : *IL FAUT MAINTENIR ALTERNC*
Dans le cas contraire, je continuerai a utiliser et maintenir Alternc
sur le site de la CNT, sans m'occuper de ce que peut faire de son cote
la communaute Alternc:
Les bases d'alternc sont simples et geniales. Il n'y a pas de
difficulte pour nous pour utiliser ce magnifique outil sans
s'encombrer d'un fonctionnement
qui repose plus sur un bricolage perpetuellement instable.
*Un systeme en exploitation ne peut pas melanger "developpement" et
"maintenance"*

Bisoux, a plux
/larpoux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD/rcfPXARFoDZvYgRAlYdAJ4nH/RRBuUkdNfUJenmc/qTEk/adQCeP+Si
m2aCny6FLMRuMUPjIjGsjDQ=
=fKo1
-----END PGP SIGNATURE-----

_______________________________________________
Dev mailing list
Dev at alternc.org
http://alternc.org/cgi-bin/mailman/listinfo/dev




Plus d'informations sur la liste de diffusion Dev