[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:38:19 CET 2006


Exactement pareil.

J'ai encore 3 machines en pre1.0-xxx (sous woody) que je n'ose pas 
migrer...
Non pas que je doute de l'excellent travail d'Anarcat sur le script 
d'upgrade, mais de tels changements auraient aussi des repercusions sur 
d'autre programmes qui tournent autour d'AlternC...
Resultat, sur l'une de ces machines j'applique quelques patchs pour 
corriger les bugs les plus embetant, et les autres restent bugges...

Ce n'est pas bien grave pour ces machines, on va finir par les changer et 
reinstaller tout le systeme, mais pour l'avenir avoir une version 
"maintain" serait vraiment bien.
Meme si la "maintain" (ou "stable") ne contient pas toutes les corrections 
de bugs inclues dans la "dev" (ou "alpha"), ce sera deja un grand pas en 
avant a mon avis ;)

-----Message d'origine-----
De:	Sebastien HEITZMANN [SMTP:2le at 2le.net]
Date:	vendredi 24 fevrier 2006 09:30
A:	Liste de Developpement de nouvelles foncti onnalites pour AlternC
Objet:	Re: [AlternC-dev] Maintenance

Bonjour,

nous sommes utilisateurs de AlternC dans une version inconnue mais qui
date un peu. Nous avons corrige un certains nombre de bug et corrections
diverses. On a participe a l'integration de awstats. Mais depuis, on a
jamais mis a jour notre version. Et ceci principalement pour les raisons
invoquee plus bas. Des changements d'architectures sont bien trop
profond pour pouvoir se faire aussi simplement qu'un update.
Je n'ai pas assez confiance pour faire un update vers une autre version
sans passez par une phase lourde de test de migration sur une autre
machine puis report des donnees, etc...

En tout cas, je suis entierement d'accord avec l'analyse de larpoux.

SEB

larpoux a ecrit :

> -----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

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




Plus d'informations sur la liste de diffusion Dev