|
Retour à l'archive de la liste Le site d'AlternC |
Bonjour, J'envisage d'utiliser alternC dans un projet à court terme, et en effet, je trouve que le principal problème est le manque de facilité dans la MAJ d'un système qui se veut facile à installer et utiliser :( Cordialement, atmaniak >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. > > >_______________________________________________ >Tech mailing list >Tech at alternc.org >http://alternc.org/cgi-bin/mailman/listinfo/tech > >.