2009/7/15 cedric.morin@yterium.com <cedric.morin@yterium.com>
Le 15 juil. 09 à 05:24, Gilles VINCENT a écrit :
L’aspect déclaratif du fichier archivelist.txt crée donc une limite qu’il faut combler :
- soit on n’a pas les derniers paquets, parce que considérés comme « trop en cours de développement » (ce qui peut se justifier, même si cela est parfois assez subjectif)
Ca reste à la discrétion du développeur non ? de décider de faire un zip? je refuse depuis longtemps de faire un zip pour inscription2 car je ne le juge pas stable… je ne crois pas que c’est toi qui ensuite essuie les plaintes des utilisateurs…
Tu as raison, je ne l’avais pas trop envisagé.
On pourrait exclure du calcul automatique des archives les plugins à l’état de « dev » :
Ça laisserait alors une souplesse pour le développeur de choisir de ne donner accès à ses travaux que via SVN, qu’en penses-tu ?
Moi je pense que dans tous les cas, c’est aux developpeurs qui vont avoir a faire la doc, le support etc … de décider si ils publient leur contribution sous forme de zip facile à installer, ou si ils ne le laissent accessibles que par SVN, à la seule intention des codeur.
Parce que mettre un zip a dispo n’est pas un acte anodin, et celui qui le fait se retrouve ensuite avec plein de sollicitations.
Sachant qu’à mon avis les plus chieurs se mettront à SVN rien que pour récupérer le plugin dans sa dernière version, j’étais d’avis de laisser l’accès le plus ouvert possible – un peu dans la logique de SPIP, quoi
Mais je maintiens que c’est une fausse solution : le seul moyen de ne pas avoir de gèneurs, c’est de développer sur son serveur SVN privé. Reste à canaliser les emmerdeurs et là dessus, peut-être que la communauté est « trop gentille » et protège mal les contributeurs…
Sinon, sur le Trac j’ai activé le temps d’une soirée une option qui permet de télécharger une archive d’une version SVN quelconque :
Essaye ce que ça donne à : http://trac.rezo.net/trac/spip-zone/browser/plugins/polyhierarchie
Redoutable, non ?
(Allez, ne me lynchez pas trop vite : ça ne restera actif que le temps de faire un sondage rapide de popularité de l’option – ensuite ce sera shutdown dans tous les cas)
Le truc pervers de ton robot c’est que tous ceux qui ne veulent pas publier le zip (pour plein de bonne raisons) vont laisser le statut dev, et ce même si c’est stable. Donc ce champ va perdre tout son sens.
Pourtant c’est logique, non ?
Il ne veut laisser le plugin que pour les « DEVeloppeurs », c’est bien qu’il considère que le plugin ne mérite pas d’être lu par tous (un peu comme un super article laissé en cours de rédaction)
Bon, j’arrete de taquiner car je me rappelle de cas plutôt pénibles que tu as vécu et je comprends la solidité de ton argument.
…
2 remarques :
- Ce n’est pas forcément le mec qui code pour spip-2.0 qui va reporter les bugs sur les branches compatibles avec SPIP1.9.x
Bah.
Dans la pratique, on a deja du mal à avoir des contributeurs qui viennent aider sur les plugins existants, et même sur ceux qui sont deja branchés, j’ai plus que rarement vu des report de patch.
Une des explications me semble liée au flou qui règle sur la façon dont on peut participer à des développements. Comment s’assurer qu’on ne va pas marcher sur les plate-bandes du développeur initial ? Je me rappelle que tu as fais un rollback d’un commit que j’avais fais sur Agenda, car ce n’était pas « dans la philosophie du plugin » – ce type de situation, ainsi que les trop vagues consignes des fichiers (jamais lus ?) expliquant comment contribue.
Le manque de méthodologie, de structure, ça fait qu’un développeur d’une contrib qui se trouve devant un contributeur qui casse (temporairement) son travail n’a aucune option pour lui donner une « seconde voie » et généralement il y a clash (ou emmerde s’il laisse faire)
Deployer une usine à gaz au pretexte que peut etre un jour un gars va avoir envie de reporter un correctif pour une vieille version me parait assez peu écologique…
Ce n’est qu’un des arguments. Ce n’est pas une usine à gaz, juste des outils pour inciter d’avantage de personnes à « se lâcher » sans qu’ils ne craignent de se faire mal voir ou de gèner.
Et ce n’est qu’une proposition qui peut-être se réduira au début à affiner la page de Trac sur l’utilisation de SVN, rien de plus…
- Je pense là surtout au « pauv’ gars » qui est devenu webmestre d’un SPIP d’une assoc’, installé il y a quelques mois par un autre développeur pas forcément très doué non plus (qu’il soit pro ou pas). On lui demande de rajouter « une super fonctionalité qu’ils ont lu sur contrib » (genre, au pif, un antispam, un formulaire, etc…). Il y en a plein qui n’oserons pas se risquer dans une mise à jour de leur site en prod, juste pour installer un plugin qui existe pour leur version mais n’est accessible que par SVN pour une version même pas forcément très identifiée…
Tu as un exemple concrêt de cas qui pose problème ?
J’ai 2 cas précis :
- un développeur professionnel avec qui j’ai eu l’occasion de travailler. Il a utilisé SPIP de façon très occasionnelle et qui a dû customiser de vieux SPIP (jusqu’à des 1.8 !). Bien sûr il n’a aucune envie de mettre à jour les versions des sites sous SPIP car il n’est pas payé pour cela – ce sont des micro-budgets ! Il lui est impossible de savoir quelle version des plugins installer et ne voit aucun maintient de compatibilité sur pas mal d’entre eux qui sont passés en 2.0 ( à tord, peut-être) ==> ça le décourage de proposer d’autres SPIP et du coup il préfère d’autres CMS dont les contribs sont mieux structurées.
- un « papy » à qui on a confié le site Internet d’une asso. Le site était sous SPIP et avais des plugins buggués. Il a voulu mettre à jour sous 1.9.2 (à l’époque) : ça a tout planté. La mise à jour des plugins n’a rien arrangé (à partir des zip). Du coup il a trouvé que SPIP c’est de la merde, a réussi (avec de l’aide externe) à revenir en arrière et ne s’occupe plus du site actuellement.
Bref 2 situations où les plugins ont donné l’impression que SPIP c’est que pour les bricoleurs.
(j’aime bien les bricoleurs, c’est un peu ma façon de fonctionner 
parce qu’a ma connaissance, les zip pour les anciennes versions sont générés, et il n’est nul besoin de SVN.
Si ils ne le sont pas, c’est alors parce que le(s) dev(s) du plugin l’ont voulu comme cela (cf les problèmes que cela pose en terme de support ensuite).
Et encore enfin, si il y a eu un oubli, un simple post sur le forum de contrib suffit à le réparer …
Oui, on va commencer par ça déjà (ainsi que du report de patchs hein
.Gilles
Cédric
