Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous
les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les
autorisations pour chacuns?). Des remarques ou objections ?
modifier les 500 plugins de la zone… je pense que tu y va un peu fort là ^^
il faudrait tous les tester, que les auteurs les modifient s’ils sont quasiment compatibles, etc…
mais c’est une bonne idée car ça permettrait de faire une réorganisation du repository de la zone !
Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous
les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les
autorisations pour chacuns?). Des remarques ou objections ?
Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les autorisations pour chacuns?). Des remarques ou objections ?
Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous
les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les
autorisations pour chacuns?). Des remarques ou objections ?
C'est une discussion annexe qui revient de temps en temps, mais j'ai fait un tour sur le browser des plugins de la zone la semaine dernière, et je trouve vraiment que passer successivement dans "dev", "test" et "stable", et y trouver de nombreux plugins dont le statut n'est pas celui auquel on s'attend, est très déroutant.
Quitte à modifier tous les plugins, ce qui serait effectivement une bonne chose, les déplacer en même temps pourrait être envisagé.
Je sais bien que c'est un espace de dev et non de diffusion, mais une autre organisation serait sans doute plus pertinente que l'actuelle.
Soit, par ordre décroissant de mes préférences :
- tout au même niveau
- avec la même organisation que sur plugins.spip.net
- par numéro de version mineure de SPIP supportée (1.8, 1.9, 2.0, 2.1, etc.)
Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous
les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les
autorisations pour chacuns?). Des remarques ou objections ?
C'est une discussion annexe qui revient de temps en temps, mais j'ai fait un tour sur le browser des plugins de la zone la semaine dernière, et je trouve vraiment que passer successivement dans "dev", "test" et "stable", et y trouver de nombreux plugins dont le statut n'est pas celui auquel on s'attend, est très déroutant.
Quitte à modifier tous les plugins, ce qui serait effectivement une bonne chose, les déplacer en même temps pourrait être envisagé.
Je sais bien que c'est un espace de dev et non de diffusion, mais une autre organisation serait sans doute plus pertinente que l'actuelle.
Soit, par ordre décroissant de mes préférences :
- tout au même niveau
- avec la même organisation que sur plugins.spip.net
- par numéro de version mineure de SPIP supportée (1.8, 1.9, 2.0, 2.1, etc.)
J'avais parlé de ca il y a quelques semaines, et je pense que c'était une bonne solution.
Et pour les plugins intercompatibles : un dossier _generique_
Le 8 déc. 08 à 11:40, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
Le 8 déc. 08 à 11:06, assobachant a écrit :
je suis d'accord sur la réflexion ; car on commence a s'y perdre ....
plus partisan d'une organisation
- par numéro de version mineure de SPIP supportée (1.8, 1.9, 2.0, 2.1, etc.)
par contre on risque une redondance car certain fonctionne sur plusieurs version de plus comment différencier
J'avais parlé de ca il y a quelques semaines, et je pense que c'était une bonne solution.
Et pour les plugins intercompatibles : un dossier _generique_
Le 8 déc. 08 à 11:40, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
Le 8 déc. 08 à 11:06, assobachant a écrit :
je suis d'accord sur la réflexion ; car on commence a s'y perdre ....
plus partisan d'une organisation
- par numéro de version mineure de SPIP supportée (1.8, 1.9, 2.0, 2.1, etc.)
par contre on risque une redondance car certain fonctionne sur plusieurs version de plus comment différencier
J'avais parlé de ca il y a quelques semaines, et je pense que c'était une bonne solution.
Et pour les plugins intercompatibles : un dossier _generique_
Franchement, bof, on voit ce que donne l'organisation actuelle, je ne pense pas qu'une organisation par version supportée soit possible dans la durée.
L'idéal me semble de tout mettre à plat, avec, dans chaque dossier d'un plugin, un trunk stable et des branches de dev, ou l'inverse pour gérer le support des différentes versions stables.
Quelle que soit l'organisation thématique qu'on pourra imaginer, il arrivera toujours un moment où cela ne conviendra pas, ou un plugin devra être dans deux thèmes, etc.
Le 8 déc. 08 à 11:40, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
Le 8 déc. 08 à 11:06, assobachant a écrit :
je suis d'accord sur la réflexion ; car on commence a s'y perdre ....
plus partisan d'une organisation
- par numéro de version mineure de SPIP supportée (1.8, 1.9, 2.0, 2.1, etc.)
par contre on risque une redondance car certain fonctionne sur plusieurs version de plus comment différencier
Le 8 décembre 2008 15:23, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
L'idéal me semble de tout mettre à plat, avec, dans chaque dossier d'un
plugin, un trunk stable et des branches de dev, ou l'inverse pour gérer le
support des différentes versions stables.
+1
la notion de dev test stable n'a plus de sens
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
Le fait qu'un plugin fasse bien ce qu'il est sensé faire
et qu'il démarre au quart de tour, ça a du sens...
Le fait qu'un autre plugin plante un site,
voire en rende la base de donnée irrécupérable,
ça a du sens aussi !
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
Il faut toutefois permettre de s'y retrouver quelquepart :
si ces distinctions ne sont pas faites par les créateurs dans la zone,
cela reporte d'autant plus sur plugins.spip.net (ou spip_contrib ?)
la responsabilité de ne présenter
que des plugins qui marchent et non dangereux.
(Sinon c'est spip lui même qui devient irresponsable !)
JL
Je compte ajouter un élément necessite (le format est-il stabilisé ?) à tous les plugins de la zone (sont-ils tous modifiables ou dois-je vérifier les autorisations pour chacuns?). Des remarques ou objections ?
Objection : pour spipbb j'ai une arbo en branche/dev selon les versions de SPIP donc nan Du moins pas au hasard !
Le 8 décembre 2008 15:23, Nicolas Hoizey <nicolas@hoizey.com> a écrit :
L'idéal me semble de tout mettre à plat, avec, dans chaque dossier d'un
plugin, un trunk stable et des branches de dev, ou l'inverse pour gérer le
support des différentes versions stables.
+1
la notion de dev test stable n'a plus de sens
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
+1
La disparition de la pseudo différence test dev stable me parait satisfaisante.
Mais je me dis qu'avec plus de 250 (?) plugins dans une meme arbo ça peut être un peu lourd... Mais j'ai pas franchement d'idée géniale à proposer... a part reprendre l'arbo faite sur plugins.spip (déjà proposé) mais ça reste... bof...
Le fait qu'un plugin fasse bien ce qu'il est sensé faire
et qu'il démarre au quart de tour, ça a du sens...
Le fait qu'un autre plugin plante un site,
voire en rende la base de donnée irrécupérable,
ça a du sens aussi !
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
Il faut toutefois permettre de s'y retrouver quelquepart :
si ces distinctions ne sont pas faites par les créateurs dans la zone,
cela reporte d'autant plus sur plugins.spip.net (ou spip_contrib ?)
la responsabilité de ne présenter
que des plugins qui marchent et non dangereux.
Et là où ça se mord la queue, c'est que contrib devrait/pourrait être renseigné automatiquement par les paquets générés depuis stables ou tests
Cédric
Le 8 décembre 2008 22:12, JLuc <jluc@no-log.org> a écrit :
Arnaud Ventre a écrit :
la notion de dev test stable n'a plus de sens
Le fait qu'un plugin fasse bien ce qu'il est sensé faire
et qu'il démarre au quart de tour, ça a du sens...
Le fait qu'un autre plugin plante un site,
voire en rende la base de donnée irrécupérable,
ça a du sens aussi !
tu as les indicateurs d'états dans plugin.xml pour ça et rien
n'empeche de gerer tout ça dans le rep local
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
Il faut toutefois permettre de s'y retrouver quelquepart :
si ces distinctions ne sont pas faites par les créateurs dans la zone,
cela reporte d'autant plus sur plugins.spip.net (ou spip_contrib ?)
la responsabilité de ne présenter
que des plugins qui marchent et non dangereux.
non la zone est un repository qui permet aux developpeurs de
travailler sur les sources , l'exposition c'est sur le site plugin,
dans contrib, dans les zip ou ailleurs ne mélangeons pas tout
Le 8 décembre 2008 22:43, cedric.morin@yterium.com
<cedric.morin@yterium.com> a écrit :
JLuc a écrit :
Arnaud Ventre a écrit :
la notion de dev test stable n'a plus de sens
Le fait qu'un plugin fasse bien ce qu'il est sensé faire
et qu'il démarre au quart de tour, ça a du sens...
Le fait qu'un autre plugin plante un site,
voire en rende la base de donnée irrécupérable,
ça a du sens aussi !
comme ça chacun gère les ramages de son plugin avec dans le petit txt
au debut pour expliquer comment c'est foutu dedans et les regles de
commits
Il faut toutefois permettre de s'y retrouver quelquepart :
si ces distinctions ne sont pas faites par les créateurs dans la zone,
cela reporte d'autant plus sur plugins.spip.net (ou spip_contrib ?)
la responsabilité de ne présenter
que des plugins qui marchent et non dangereux.
Et là où ça se mord la queue, c'est que contrib devrait/pourrait être
renseigné automatiquement par les paquets générés depuis stables ou tests
Cédric
Pas tout suivi, la generation des paquets et du flux rss c'est pilote
par archivelist, aucun rapport avec l'arbo non ?
------------------------------
Arnaud
Le 8 décembre 2008 23:06, Yohann Prigent <prigent.yohann@gmail.com> a écrit :
le meilleur est de faire par versions de spip suportés...
pas d'accord, tu as des plugins trans-version, d'autre non ... ingérable...
le support des version c'est dans plugin.xml
Une proposition :
Conserver les dev stable tests MAIS avoir la rigeur de chacun pour ne commiter que dans DEV et une fois que l'on a une version dite STABLE alors on crée le répertoire dans STABLE et on copie la version de DEV dans STABLE ( ce qui en théorie aurait du être le cas avant ... ). Et dans STABLE, on ne fait que corriger les bugs de la version que l'on croyait stable.
Un sous répertoire de STABLE donc pour chacune des versions mineures de SPIP si on en a besoin.
une génération automatique ( ou avec archive list ) de TOUS les plugins dit stable avec chacune de leur sous version (par version mineure de SPIP)
Le seul truc a faire a mon avis est d'être rigoureux de ce coté.
Certes, cela implique probablement plus de boulot au niveau des commit quand on corrige un bug, mais si on cherche quelque chose on ne va pas le chercher dans 3 répertoires.
Si on cherche un plugin qui a été commencé aussi on pourra le trouver dans TEST , dés qu'il a un semblant de fonctionnement , il passe dans DEV , et dès qu'il est stable il est copié dans STABLE .
C'est un peu le fonctionnement de SPIP ( qui d'ailleurs est relativement classique a l'utilisation d'un dépot http://svnbook.red-bean.com/ )
