Suite aux commits d’un nouvel empaqueteur de Cedric que fait-on ?
Ce soir je peux le tester en marche en double sur le serveur de files.spip.org pour les paquets de la zone et de spip (j’ai vu que les dernieres modifs permettent de passer des paramètres, et que les tags pour spip-dev sont là). Si tout se passe bien je devrai pouvoir basculer les scripts sans trop de probleme. (juste à modifier grospaquets.sh)
Pour les depannages en cas d’urgence/vacances j’ai crée des comptes qui permettent à Ben et Fil d’acceder à cette partie du serveur (s’il y a d’autres candidats c’est faisable tant que c’est pas toute la zone).
Si on déplace les paquets pas de soucis faudra juste me dire si je demonte tout / une partie … (je peux aussi laisser tourner en backup au cas où …)
Nb: pour les flux rss pas eu de retour sur l’utilité donc rip ?
salut,
moi aussi je suis de retour ... Bravo Cedric pour le script .
Je pense par contre qu'il faut laisser files.spip.org ( et migrer
avec le script de cedric pour la génération des paquets ... une
petite pensée pour les scripts ksh de toggg et la nouvelle
mouture d'arnaud )
sur spip-contrib tu laisses le lien sur paquet si tu veux mais
je pense que c'est tout de même mieux de revenir en arrière
et laisser files.spip.org ( c'est mieux rangé ) ... m'enfin comme
tu le sens
2009/8/4 Arnaud Ventre <ventrea@gmail.com>:
De retour aux affaires après un peu de repos
Suite aux commits d'un nouvel empaqueteur de Cedric que fait-on ?
Ce soir je peux le tester en marche en double sur le serveur de
files.spip.org pour les paquets de la zone et de spip (j'ai vu que les
dernieres modifs permettent de passer des paramètres, et que les tags pour
spip-dev sont là). Si tout se passe bien je devrai pouvoir basculer les
scripts sans trop de probleme. (juste à modifier grospaquets.sh)
Pour les depannages en cas d'urgence/vacances j'ai crée des comptes qui
permettent à Ben et Fil d'acceder à cette partie du serveur (s'il y a
d'autres candidats c'est faisable tant que c'est pas toute la zone).
Si on déplace les paquets pas de soucis faudra juste me dire si je demonte
tout / une partie ... (je peux aussi laisser tourner en backup au cas où ..)
Nb: pour les flux rss pas eu de retour sur l'utilité donc rip ?
salut,
moi aussi je suis de retour ... Bravo Cedric pour le script .
Je pense par contre qu'il faut laisser files.spip.org ( et migrer
avec le script de cedric pour la génération des paquets ... une
petite pensée pour les scripts ksh de toggg et la nouvelle
mouture d'arnaud )
sur spip-contrib tu laisses le lien sur paquet si tu veux mais
je pense que c'est tout de même mieux de revenir en arrière
et laisser files.spip.org ( c'est mieux rangé ) ... m'enfin comme
tu le sens
oui, mais pour présenter la ?page=paquets a jour etc ... il faut que contrib et files.spip.org soient le meme serveur.
Du coup il est probable que le plus simple soit de deplacer le sous domaine sur le serveur de contrib
Je finis les tests et l'install et je vous dis cela.
salut,
moi aussi je suis de retour … Bravo Cedric pour le script .
Je pense par contre qu’il faut laisser files.spip.org ( et migrer
avec le script de cedric pour la génération des paquets … une
petite pensée pour les scripts ksh de toggg et la nouvelle
mouture d’arnaud )
sur spip-contrib tu laisses le lien sur paquet si tu veux mais
je pense que c’est tout de même mieux de revenir en arrière
et laisser files.spip.org ( c’est mieux rangé ) … m’enfin comme
tu le sens
oui, mais pour présenter la ?page=paquets a jour etc … il faut que contrib et files.spip.org soient le meme serveur.
heu pourquoi créer une dépendance physique juste à cause d’un page qui ne fait que lister les paquets ??
salut,
moi aussi je suis de retour … Bravo Cedric pour le script .
Je pense par contre qu’il faut laisser files.spip.org ( et migrer
avec le script de cedric pour la génération des paquets … une
petite pensée pour les scripts ksh de toggg et la nouvelle
mouture d’arnaud )
sur spip-contrib tu laisses le lien sur paquet si tu veux mais
je pense que c’est tout de même mieux de revenir en arrière
et laisser files.spip.org ( c’est mieux rangé ) … m’enfin comme
tu le sens
oui, mais pour présenter la ?page=paquets a jour etc … il faut que contrib et files.spip.org soient le meme serveur.
heu pourquoi créer une dépendance physique juste à cause d’un page qui ne fait que lister les paquets ??
sinon il faut faire recuperer_page, extraire_balises …
Mais je prends toute proposition qui marche à distance !
Cédric
methode pas beau mais rapide : une iframe
plus propre je genere un fichier (format à préciser) qui est utilisé par la page paquet , tu en fait un tableau (le format du fichier d’echange est utile ici) que tu balayes dans ta boucle à la place de ton eval dir …
tiens d’ailleurs le flux rss servait à ça à une époque si mes souvenirs sont bons
sinon il faut faire recuperer_page, extraire_balises …
Mais je prends toute proposition qui marche à distance !
Cédric
methode pas beau mais rapide : une iframe
plus propre je genere un fichier (format à préciser) qui est utilisé par la page paquet , tu en fait un tableau (le format du fichier d’echange est utile ici) que tu balayes dans ta boucle à la place de ton eval dir …
tiens d’ailleurs le flux rss servait à ça à une époque si mes souvenirs sont bons
je vois l’idée : il faut que l’empaqueteur genere le xml qui va bien dans le meme process, et le depose avec les zips, non ?
J’ai pas très envie de refaire le rss complet car il est inutilement verbeux
Je pense a un xml dedie plus smart, si possible genre une section par fichier
chemin/vers/archive.zip
…
…
avec la section qui reprend en fait le contenu de plugin.xml si present a la racine du paquet.
Du coup cote contrib on recupere le fichier xml simplement et on boucle dessus.
Je regarde pour ajouter cela à l’empaqueteur
Des que tout marche je te dis
Cédric
sinon il faut faire recuperer_page, extraire_balises …
Mais je prends toute proposition qui marche à distance !
Cédric
methode pas beau mais rapide : une iframe
plus propre je genere un fichier (format à préciser) qui est utilisé par la page paquet , tu en fait un tableau (le format du fichier d’echange est utile ici) que tu balayes dans ta boucle à la place de ton eval dir …
tiens d’ailleurs le flux rss servait à ça à une époque si mes souvenirs sont bons
je vois l’idée : il faut que l’empaqueteur genere le xml qui va bien dans le meme process, et le depose avec les zips, non ?
J’ai pas très envie de refaire le rss complet car il est inutilement verbeux
Je pense a un xml dedie plus smart, si possible genre une section par fichier
chemin/vers/archive.zip
…
…
avec la section qui reprend en fait le contenu de plugin.xml si present a la racine du paquet.
Du coup cote contrib on recupere le fichier xml simplement et on boucle dessus.
Je regarde pour ajouter cela à l’empaqueteur
Des que tout marche je te dis
Cédric
sinon te prends pas le chou je fais 2 ligne de php pour le generer à la volée
Tu n’as donc plus qu’a l’installer sur ton serveur :
il suffit simplement de le checkout la ou ça t’arrange :
svn checkout svn://zone.spip.org/spip-zone/outils/smart_paquets
edite le script cron-paquets.sh dans le répertoire pour changer éventuellement le path
(la seule contrainte est de lancer empaqueteur depuis le répertoire smart_paquets)
Au premier lancement il va faire les checkout et créer les répertoires, et après tout roule tout seul en principe.
sinon il faut faire recuperer_page, extraire_balises …
Mais je prends toute proposition qui marche à distance !
Cédric
methode pas beau mais rapide : une iframe
plus propre je genere un fichier (format à préciser) qui est utilisé par la page paquet , tu en fait un tableau (le format du fichier d’echange est utile ici) que tu balayes dans ta boucle à la place de ton eval dir …
tiens d’ailleurs le flux rss servait à ça à une époque si mes souvenirs sont bons
je vois l’idée : il faut que l’empaqueteur genere le xml qui va bien dans le meme process, et le depose avec les zips, non ?
J’ai pas très envie de refaire le rss complet car il est inutilement verbeux
Je pense a un xml dedie plus smart, si possible genre une section par fichier
chemin/vers/archive.zip
…
…
avec la section qui reprend en fait le contenu de plugin.xml si present a la racine du paquet.
Du coup cote contrib on recupere le fichier xml simplement et on boucle dessus.
Je regarde pour ajouter cela à l’empaqueteur
Des que tout marche je te dis
Cédric
sinon te prends pas le chou je fais 2 ligne de php pour le generer à la volée
pour moi l'interet c'est de garder files.spip.org mais tu ne parles
pas de ça, tu parles de la même machine physique .
Je pense aussi qu'il faut garder files.spip.org comme nom de domaine,
pour pouvoir séparer de nouveau si on a une meilleure idée. C'est ce
que j'ai dit tout de suite hier à Cerdic quand j'ai vu ses modifs.
Mais faire des trucs distants qu'on synchronise de manière pénible
alors que le script peut tourner en local, ça me paraît une simple
perte de temps.
L'intéret que j'y vois c'est qu'arnaud garde cette partie, cela
"divise" un peu les tâches et les responsabilités.
Justement
Des tâches à prendre en responsabilité, j'en ai une liste longue comme
le bras, car même si j'ai pas mal délesté ces derniers temps, je fais
encore *beaucoup* trop de choses dans SPIP. de ce point de vue,
Arnaud, ne te sens pas "rejeté" si on ne conserve pas ton serveur, au
contraire c'est l'occasion de te mettre sur un nouveau truc.
Personnellement je ne demande que ça !
Des tâches à prendre en responsabilité, j’en ai une liste longue comme
le bras, car même si j’ai pas mal délesté ces derniers temps, je fais
encore beaucoup trop de choses dans SPIP. de ce point de vue,
Arnaud, ne te sens pas « rejeté » si on ne conserve pas ton serveur, au
contraire c’est l’occasion de te mettre sur un nouveau truc.
Personnellement je ne demande que ça !
Pas de soucis :-b , j’ai aussi pas mal de truc sur le feu par ailleurs et ma dispo pour Spip etait assez limitée, le principal est de savoir qui fait quoi pour eviter de les faire en double
?
)
