[AlternC-tech] Re: [lautre-techos] re : Re: [lautre-techos] A quoi sert lautre3 ?

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

Jerome Moinet jerome at globenet.org
Dim 20 Avr 12:12:42 CEST 2003


Bonjour,

petit résumé de la situation alternc.

Alternc est un projet fort sympathique, mais qui souffre d'un grave défaut :
il n'y a toujours pas de première distribution stable et figée, de version
1.0, et donc toujours pas de protocole de mise à jour unifiée pour tous les
serveurs l'utilisant (et il commence à y avoir un certain nombre de serveurs
tournant sous alternc...).

Par conséquent, chaque serveur se retrouve avec des patchs fait à la main
qui résolvent tel ou tel problème ou ajoutent telle ou telle fonctionnalité,
sans que ces patchs soient forcemment inclus dans le cvs de la version en
cours de dev, et de toute façon, vu qu'il n'y a pas de protocole d'upgrade
de version, ces patchs/corrections peuvent dificilement se propager à part
en les appliquant à la main au coup par coup comme le fait benjamin.

Bref, c'est le bordel, et malheureusement le but premier d'alternc, à savoir
avoir une distribution communemment utilisée par plusieurs strucuture
s'échangeant leur améliorations/correction de bugs au travers d'un système
solide de versionning et d'upgrade de version, n'est pas atteint.

Ce qu'il faudrait certainement faire pour remédier à cet état de fait :

* figer la version en cours, ie stoppper le codage de nouvelles
fonctionnalités (ou les déplacer dans une branche).
* mettre en place un protocole de tests d'intégration permettant de valider
l'installation, le fonctionnement et le protocole d'upgrade vers des version
ultérieures.
* effectuer ces tests sur plusieurs serveurs (lautre2 pour lautre net,
d'autres serveurs pour d'autres structures)
* remonter les fiches d'anomalie au niveau de l'équipe de dev alternc (dans
le mantis), et les corriger.
* releaser une bonne fois pour toutes la V1.0 officiellement
* l'installer sur tous les serveurs utilisant alternc.

A partir de là, tout nouveau bug corrigé, toute nouvelle focntionnalité,
pourra être appliquée à TOUS les serveurs au moyen soit d'un apt-get
upgrade, soit de tout autre moyen d'application de patch. Nous rentrerons
dans une logique de versionning, passant de la V1.0 à la V1.0.1, puis à la
V1.0.2, etc... jusqu'à ce que les fonctionnalités/corrections de bugs soient
suffisement conséquents pour pouvoir passer à une V2.0, et TOUS les serveurs
fonctionnerons sur la même version, rendant efficace et cohérent la
gestion/correction des bugs et l'ajout de nouvelles fonctionnalités.

Pourquoi ne partons nous pas dans cette direction ?

Tout simplement parce que, grosso modo, il n'y a qu'un seul dévellopeur qui
code sur alternc, à savoir benjamin, et qu'icelui étant salarié de globenet,
il code selon les besoins de globenet (ou selon ce qui l'interresse sur le
moment), ce qui est tout à fait légitime, et ce que devrait faire chacune
des structures utilisant alternc, et qu'à partir de là, il ne va pas en plus
s'occuper des releases.

Alternc manque à mon sens cruellement d'une équipe d'intégration/validation
qui appliquerais le schéma suivant :

Aller-retour dévellopement <--> intégration
validation
Re-aller-retour dévellopement <--> intégration + re-validation (en cas de
bugs bloquants)
Tagguage dans le cvs et release de version.
annonce sur la mailing liste d'annonces (genre release at alternc.org)

Il me semblerait donc interressant de créer une liste integ at alternc.org,
dont l'objectif d'ici 2 à 3 semaines serait de :

* mettre d'équerre la procédure d'installation et mettre en place la
procédure d'upgrade ou de patch de version
* rédiger les fiches de tests permettant de valider l'installation,
l'upgrade et le fonctionnement d'une version
* appliquer ces tests à la version en cours sur un ou des serveurs
d'intégration (lautre2 est fait pour ça)
* effectuer les aller-retour avec l'équipe de dev pour corriger le max de
bugs bloquants
* valider une fois pour toute la version 1.0
* releaser la version (tagguage dans cvs, construction de l'archive
d'install, mise en ligne et annonce)

Ensuite, la répartition devellopement/intégration pourrait être la suivante
:
* l'équipe de dev (tech at alternc.org, ou renommage en dev at alternc.org) code
les nouvelles fonctionnalités, corrige les bugs et gère les aller-retour
avec les utilisateurs concernant la partie utilisation d'alternc
* l'équipe d'intégration (integ at alternc.org) valide les dev, gère les
procédures d'installation/upgrade ainsi que la release ou patchs de version
(ie tagguage dans cvs et génération de l'archive) et gère les aller-retour
avec les utilisateurs concernant la partie installation/patch/upgrade
d'alternc

Il me semble que cette organisation, si toutefois il y a suffisemment de
personnes pour s'y investir, pourrait être bénéfique à AlternC.

cdlt,

jerome m.




Plus d'informations sur la liste de diffusion Dev