CR reunion 10/01/04
- Présents:
- erwan
- olivier
- pierre
- peter
- antoine
- charles
- gil
- youssef
- cheick
- jean-luc
- mathieu
Contents |
Point sur l'avancement neogia 2.0
News
- pas de date de fin de projet
- pour l'instant on est surtout sur des nouvelles fonctions
- peu d'usage des générateurs ( version 2 est en cours de réalisation-validation-test)
- prochain jalon sur Neogia 2.0, une version un peu stable de l'usage des addons
- toutes les semaines il y a entre 2 ou 3 nouveaux addons sur le serveur d'intégration
- être performant sur des nouvelles fonctions, en passer moins sur les outils
Reprise de l'existant de Neogia
- antoine : au niveau de Facility, je commence à ne pas perdre trop de temps quand je developpe. J'ai quasiment fini l'addon FacilityStatus qui permet de mettre un status sur un emplacement, et j'ai bien avancé sur les inventaires! il faut que je remette le nez dans Neogia pour rester cohérant. Je trouve pas évident de faire du copier coller de l'existant dans ofbiz ... (surtout si on veut que cela soit intégrer dans ofbiz plus tard)
Planning prévu et les taches de chacun sur ce point précis
- olivier : en terme de planning, ce sont les projets qui peuvent nous tirer
Infos pour tester neogia 2.0 (addons à installer ? quelle version d'ofbiz prendre ?)
- mettre sur la page d'accueil un lien vers une présentation de néogia 2.0
- écrire un texte descriptif et réunir l'ensemble des liens et médias sur les addons
- décrire la procédure pour 3-4 addons ?
- avoir une page index.html sur addons.neogia.org qui redirige vers la page wiki ?
- avoir la totalité des helps de tous les addon disponible ?
- au niveau des pages wiki sur l'addon manager, mettre un lien et quelques explications dans la pages Téléchargement ? - > olivier : ajout d'une pages Neogia 2.0 dans le menu de gauche Téléchargement
- routime pour transformer les docbook en html ou wiki ? manuellement ça ira plus vite
- Neogia2.0 n'est pas une version packagée d'addon ? pas encore et pas trés rapidement
- 15 lignes de textes : olivier, Gil ( completer usecase, et autres...), antoine (description de la procedure d'installation et configuration pour les 3/4 addons), cheick (?)
Bilan neogia 2.0
- pas de date de fin de projet (pas de planning non plus)
- augmenter la com et la visibilité des addons (points précédents)
- prochain jalon, version stable de l'usage des addons
Versionning des addons
Point important : est-il problématique qu'une version de dev soit chargée si lors de l'installation la personne n'a pas précisé la version ?
- la dernière version est celle par défaut à mon avis et donc un addon "stable" connait les versions "stables" de ses dépendances (romain)
- stable ne veut pas dire utilisable (pierre, olivier)
- publication après revue du développeur, puis puis déclaration utilisable = stable
- publication des versions de dév ? faciliter la vie des testeurs, pour les dépendances
- liste des addons ? ceux suivis par la liste sur selenium.neogia.org
Débat sur la numérotation de version
- numéro de version devrait indiquer le statut ?
- statuts :
- en cours de dév => que sur le svn
- developpé en cours de validation => publié en version Dxxxx puis X.Y-rc1....
- stable => publié en X.Y.Z
- en standard, plutot x.x.x.dev .rc ou -rc ? pour les versions de devs ?
- caractère au début ? pour obliger ivy à prendre la stable en prio (pouvoir publié sans être pris par defaut)
- pas besoin de lettre pour le stable (erreur de jeunesse)
- maitriser le comportement par défaut : on peut dire que chacun prend ces responsabilités, donc si quelqu'un ne précise pas de version c'est son soucis (olivier)
- lecture de fichier Ivy : ne lit pas la version ivy à la racine du rep => compare ce qu'il y a dans les répertoires
- modifier ivy : tout ce qu'il faut pour, pas le temps (romain : master ivy ? test)
- gestion des numero dans les règle de l'art avec une convention d'appel versionné pour les testeur, on réglera le pb plus tard d'ivy (impact sur les admin et non pas sur les devs)
- nettoie et refactorise l'existant de l'adm (youssef)
Bilan addons
- versions stables sans lettre, toujours prises en priorité (1.8 devant V1.9)
- dernière version publiée = installée (après si on veut du stable on le spécifie)
- numéro de version suivant les règle de ivy (POC du master-ivy)


