[AlternC-dev] Maintenance

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

Sébastien HEITZMANN 2le at 2le.net
Ven 24 Fév 09:29:57 CET 2006


Bonjour,

nous sommes utilisateurs de AlternC dans une version inconnue mais qui 
date un peu. Nous avons corrigé un certains nombre de bug et corrections 
diverses. On a participé à l'intégration de awstats. Mais depuis, on a 
jamais mis à jour notre version. Et ceci principalement pour les raisons 
invoquée 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 données, etc...

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

SEB

larpoux a écrit :

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The Anarcat a écrit :
>
> |
> | Ce que tu demandes, en bref, c'est un "fork" entre une version
> | stable et de développement.
> |
> | Je ne crois pas qu'il y ait suffisamment d'énergie dans l'équipe
> | pour faire une telle maintenance.
>
> Salux à toux,
>
> Je répond avec deux semaines de retard à ce post tellement il m'a
> estomaqué.
> Cette réponse est réellement pour faire avancer le navire et pas du
> tout une manifestation d'une attitude négative.
>
> Après bientôt 40 ans d'experience de programmeur/chef de projet c'est
> la première fois que je rencontre
> un projet qui à la prétention de pouvoir exister sans maintenance.
>
> Nous avons installé il y a un an la version 0.9.3 et nouvs avons
> évidemment rencontré un nombre certain de bugs.
> Chque fois que j'ai voulu m'adresser à l'équipe de developpement les
> réponses étaient de deux type (du moins quand il y avait réponse :-~)
> - - Ce bug est bien connu est il est corrigé dans la prochaine version 
> (CVS)
> - - Encore pire : il est connu et a été fixé sur le site de Globenet
> (mais il n'est pas dans CVS)
>
> Puis sortie de la version 0.9.3.1. Nous l'avons intallé afin de
> bénéficier des differents "fixs" effectués.
> Du coup on se retrouve maintenant avec un certain nombre de bugs
> corrigés, plus un nombre probablement équivalent (voir plus)
> de bugs introduits par des dévelopements divers (notamment
> l'authentification dans le MTA)
>
> Les nouveaux bugs vont être corrigés 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 même temps on va rajouter plein de nouveaux bugs
> qui vont avoir avec par exemple :
> - - le passage de PHP4 à PHP5
> - - le passage de apache à apach2
> - - l'utilisation de XML pour gerer le bureau,
> - - ...
>
> Resultat alternc reste en permanence avec :
> - - des bugs connus mais non corrigés pendant un temps important
> - - des nouveaux bugs qui sont introduit chaque fois qu'on veut
> bénéficier d'un peu de maintenance
>
> La question n'est pas de savoir si ça coûte de l'energie pour faire de
> la maintenance, mais de comprendre qu'un projet
> sans maintenance ne poura jamais exister.
> Si la communauté Alternc pense qu'il n'est *pas* possible de faire à
> la fois des développements et de la maintenance
> la *SEULE* conclusion possible est de dire qu'on ne peut plus faire de
> développements.
>
> Mais je voudrais mettre un bémol au post d'Anarcat :
> j'ai passé un temps très important dans ma vie à faire de la maintenance.
> Mon expérience 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
> général pas une charge énorme de reporter le fix dans deux versions,
> (voir quelque fois 3 version) :
> - - la version "maintain"
> - - la version "alpha"
> (la version "beta")
>
> La qualité d'un fix dans une version "maintain" ne se mesure en
> général pas de la même façon que dans une version "alpha". Un patch
> est de bonne qualité dans une version '"maintain" :
> - - Quand il corrige un vrai problème
> - - S'il modifie un nombre le plus faible possible de lignes.
>
> C'est un problème 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 qualité.
> Un patch qui fait intervenir 20 lignes a de bonne chance d'introduire
> deux nouveaux problèmes en en corrigeant qu'un seul.
>
> Dans 90% des cas au minimum, une correction peut être appliquée d'une
> manière identique dans une version alpha et dans une version "maintain".
> Quelque fois, il faut revoir le design dans la version de
> développement pour corriger un nid de problèmes.
> Dans ce cas, il ne faut évidemment pas revoir le design dans la
> version maintain : il faut coûte que coûte appliquer quelques patchs
> verrue, et vivre avec jusqu'à
> la validation et la sortie de la nouvelle version.
>
> Sur un autre sujet, un peu similaire, j'ai constaté hier avec un peu
> d'inquietude
> - - qu'un bug a été mis en évidence au niveau de l'interface avec 
> phpmyadmin
> - - un commit dans alternc a été fait rapidement
> - - un autre camarade a constaté que ça ne marchait pas du tout
>
> Peut être acceptable sur une version alpha (qui va passer normalement
> ensuite l'étape 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
> méthodologie de développement conforme à quelques principes basics
> absoluement pas négociable : *IL FAUT MAINTENIR ALTERNC*
> Dans le cas contraire, je continuerai à utiliser et maintenir Alternc
> sur le site de la CNT, sans m'occuper de ce que peut faire de son côté
> la communauté Alternc:
> Les bases d'alternc sont simples et géniales. Il n'y a pas de
> difficulté pour nous pour utiliser ce magnifique outil sans
> s'encombrer d'un fonctionnement
> qui repose plus sur un bricolage perpetuellement instable.
> *Un système en exploitation ne peut pas mélanger "développement" 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