Bonjour tout le monde,

Ceux qui recoivent les messages de "commit" de SVN auront vu qu'il y a eu 
quelques mouvements sur Ncooker ce week-end. Je vous livre ici mon 
compte-rendu.


Eclatement du fichier infos
------------------------------

Ce week-end, Ncooker a pris un nouveau virage. La branche 
ncooker-bursting-infos, que je jugais suffisament stable, a été reportée 
dans la branche principale (trunk/ncooker).

Maintenant que le report est fait, la branche ncooker-bursting-infos permet 
de convertir un fichier infos en multiples fichiers (project, package, 
changelog). Pour cela, il suffit d'appeler la commande pack. Si tout se 
passe bien, les trois nouveaux fichiers seront créés. Je continuerai à 
maintenir cette branche si des anomalies sont trouvées.

Avant d'effectuer le report, j'ai créé une étiquette ncooker-with-infos à 
partir de la branche principale. Cela nous permettra de revenir en arrière, 
au cas où on s'apercevrait que le fichier "infos" était mieux...

Après le report, j'ai fait des modifications pour supprimer toutes 
références au fichier "infos". Le virage vers les fichiers de propriétés est 
donc complètement opéré.

Une fois de plus, je vous invite à tester cette nouvelle version :
http://www.nasgaia.org/wiki/doku.php?id=tester_ncooker


"Killer feature"
------------------------------

Il y a quelques jours, j'avais parlé d'une "killer feature". J'y suis 
peut-être allé un peu fort. Ce sera à vous de juger.

La "killer feature" consiste à pouvoir utiliser la commande wizard avec une 
URL de ressource. A partir de l'URL, Ncooker essaie de récupérer le nom du 
projet et le numéro de sortie puis il initialise les propriétés 
correspondantes dans le fichier project. Evidemment, le nom et l'adresse de 
la ressource sont également initialisés. Ainsi, le Nbuild est quasiment prêt 
à être empaqueté.

J'espère que cette fonctionnalité vous plaira.


Commandes wizard/pack
------------------------------

Je compte maintenant m'attaquer aux comportements des commandes wizard et 
pack. Selon moi, la première pourrait faire plus de choses et la deuxième en 
fait trop. Je vais tenter de vous exprimer ma pensée.

Actuellement, la commande pack effectue automatiquement les opérations 
suivantes avant de créer le paquet :
- il ajoute l'identifiant du fournisseur ("nga" par exemple)
- il ajoute la version du format Npkg
- il télécharge les ressources, calcule les sommes de contrôle (checksum) et 
les ajoute
- il ajoute le mainteneur du paquet (celui qui exécute la commande pack)
- il ajoute ou met à jour l'entête du changelog

A une époque, tout cela était fait dans le répertoire donné en argument à la 
commande pack. Cela ne me plaisait pas car Ncooker faisait des modifications 
sur des fichiers qui étaient potentielement ouverts dans un éditeur de 
texte. J'avais donc demandé à Gontran de faire en sorte que la commande pack 
recopie les fichiers dans un répertoire temporaire avant d'y apporter des 
modifications. C'est ce qui est fait actuellement.

Avec le recul, je me suis rendu compte que ma demande n'était pas totalement 
pertinente. En effet, comme les fichiers du répertoire Nbuild ne sont pas 
modifiés, les fichiers restent dans un état ne respectant pas le format 
Npkg. Par exemple, les sommes de contrôle sont manquants. Ainsi, le 
répertoire sera mis tel quel sur le dépôt SVN. Première aberration : les 
fichiers déposé sur SVN ne respectent pas le format Npkg.

D'autre part, des propriétés comme le mainteneur sont systématiquement 
modifiées par celui qui exécute la commande pack. Or, une personne peut 
avoir simplement récupéré un répertoire Nbuild depuis un dépôt SVN. S'il 
exécute la commande pack, en n'ayant effectué aucune modification aux 
fichiers, il se retrouve le mainteneur du paquet. Deuxième aberration : le 
mainteneur d'un paquet Nbuild n'est pas celui qui a créé les fichiers, mais 
celui qui a lancé la commande pack.

Ces deux aberrations m'amènent à la proposition suivante : les opérations 
actuellement effectuées par la commande pack (celles listées plus haut) 
doivent être effectuée par la commande wizard.

Toutes les opérations peuvent être faites par la commande wizard. Le cas des 
sommes de contrôle est cependant particulier. Etant donné que les sommes de 
contrôles ne peuvent être calculées qu'à partir du moment où des URLs de 
ressources sont fournies, le développeur de Nbuild devra relancer la 
commande wizard après la modification d'une URL de ressources, ou l'ajout 
d'une ressource.

Classiquement, voilà ce que devra faire un développeur de Nbuild lorsqu'il 
voudra créer un nouveau paquet :
$ Ncooker wizard <paquet>
$ vi <paquet>/project
Ajout d'une ressource (avec son URL)
:q
$ Ncooker wizard <paquet>
$ gvim <paquet>/project <paquet>/package <paquet>/changelog ...
$ Ncooker pack <paquet>


ou bien, plus simplement :
$ Ncooker wizard <URL de la ressource du paquet>
$ gvim <paquet>/project <paquet>/package <paquet>/changelog ...
$ Ncooker pack <paquet>

Qu'est-ce que vous en dites ?


Options de la commande wizard
------------------------------

J'ai pensé à une autre amélioration de la commande wizard. Je crois qu'il 
pourrait être intéressant d'utiliser la commande wizard pour modifier le 
numéro de sortie de projet (project release number) d'un paquet. C'est la 
maintenance typique qui est faite sur un paquet.

Je propose pour cela d'ajouter une option à la commande wizard qui prendrait 
le nouveau numéro de sortie du projet. Lorsqu'un nouveau numéro de sortie 
serait donné, le numéro de correction du paquet serait réinitialisé 
automatiquement à 1.

Dans la même foulée, je crois qu'une option similaire pourrait être ajoutée 
pour fixer un nouveau numéro de correction de paquet.

Une fois de plus, qu'est-ce que vous en pensez ?

Voilà tout ce que je voulais vous dire. J'espère que je n'ai pas été trop 
long.
J'attends vos réponses avec impatience.

--
JulienL

_________________________________________________________________
Gagnez des pc Windows Vista avec Live.com http://www.image-addict.fr/


_______________________________________________
Nasgaia-dev mailing list
[email protected]
https://mail.gna.org/listinfo/nasgaia-dev

Répondre à