-----Message d’origine-----
De : spip-lab-bounces@rezo.net [mailto:spip-lab-bounces@rezo.net] De la part de Christian Lefebvre
Envoyé : mardi 26 octobre 2004 23:05
À : spip-lab@rezo.net
Objet : [spip-lab] Faut il arréter là ?Salut la liste …
Le titre est volontairement provocateur, mais l’idée qui est derrière n’est pas un troll, juste une question de fond qui me trotte dans la tête.
On a actuellement plusieurs « courants » qui ne vont pas tous dans le même sens, et qui obligent constamment à jongler dans tous les sens :
d’un coté, le courant « spip canal historique », avec la volonté
d’avoir un produit unique, installable partout et par n’importe qui,
le refus d’ajouter des fonctionnalités qui sortent de l’esprit
initial, en termes de flicage, de complexité et de spécificité …de l’autre, un tas d’utilisateurs qui, comme tout utilisateur, en
veulent plus, disent que typo3/agora/vignette/xyz c’est mieux, que
telle contrib serait super à intégrer dans le core, que telle
fonctionnalité serait fondamentale etc…au milieu, le nouveau compilo ouvre des portes sur des possibilités
qu’on n’imaginait pas jusqu’à présent autrement qu’en tonnes de code
et de modifs du core.à coté de ça, plein de contribs, de « à peine ébauché » à « très
finalisé », de « immédiate à installer » à « impliquant des modifs
profondes du core », de « installable partout » à « spécifique telle
version, nécessite xyz sur le serveur et compatible IE5.5 et
rien d’autre ».en face, un labo qui vivote mais qui dès le départ c’est retrouvé
avec un code radicalement différent de celui du core, et donc
des problématiques de backports assez balaises, dans un sens
comme dans l’autre.Au milieu de tout ça, quelques chantiers ont été ébauchés, mais personne ne sait encore ce que ça deviendra. Le principal (en conséquences, pas en état d’avancement) étant la généralisation du nouveau compilo coté admin.
À mon avis, ce chantier pose un problème de fond : ou est sa place ?
- dans le core : ça implique de potasser les problématiques de
compatibilité et de ne rien sortir tant que ça n’est pas stable.
De plus, ça amène à un outil tellement élastique, qu’il n’aura
plus rien à voir avec spip 1.7, et que le coté « on peut saisir le gros
du truc en quelques jours » sera complètement foutu.- dans le labo : ça implique de backporter le compilo déjà, ainsi que
certains ajouts du core qu’il serait dommage de perdre en route.
D’un autre coté, on est en plein dans le but initial du labo :
couper les pont avec spip core, et en profiter pour se lacher sur
de nouvelles fonctionnalités.- en contrib : outre la difficulté de faire ça en groupe (ou alors il
faut un cvs à part), ça implique de suivre l’évolution du core en
parallèle pour ne pas se retrouver dans la m… le jour où on voudra
faire le merge.
Et vu la taille du chantier, ça me parait bien plus qu’une contrib,
on sort complètement de l’esprit d’une contribBref, pour moi, ce chantier sort du périmètre de spip 1.*, et entre plutôt, comme ça a été évoqué plusieurs fois dans un spip 2. Et ça, si j’ai pas tout compris de travers, c’est un peu le but du lab.
Du coup, spip 1 continuerait à « vivre sa vie » mais commencerait à tendre vers l’asymptote, c’est à dire une stabilisation des fonctionnalités (d’où le titre).Ensuite, le principe même (extensibilité poussée) du nouveau compilo et de son pendant coté admin ouvre la porte à un tas de contribs astronomiques. De mêmes, des fonctions de base du spip actuel seront tellement paramétrables, qu’on pourrait imaginer de disposer d’un « paramétrage standard » correspondant fonctionnellement à la version actuelle et des paramétrages plus dédiés à des variantes en tous genres.
Du coup, l’idée d’un spip « en légo » m’est venue :
- le compilo est lui même assez modulaire, permettant de faire des
paquets « parseur de squelettes », « compilo », « cache » …- d’autres parties existent déjà en plusieurs versions (authentification
htaccess, bdd ou ldap par exemple)- d’autres sont en projet (multi base)
- et certains projets y trouveraient leur compte (multi site)
Alors pourquoi ne pas organiser ça en paquets distincts permettant de monter une « distribution spip » comme il y a des distribs linux permettant de choisir gnome, kde ou fvwm2 ?
On pourrait alors faire une distrib « standard » contenant les paquets qui vont bien pour avoir le même fonctionnel qu’actuellement, et des distrib fondées sur des paquets plus au moins pointus ou exotiques.Bien sur, cela nécessite de définir des api assez précises pour que les paquets sachent causer entre eux, mais à mon avis, cela peut se faire petit à petit : une fois qu’une première version de packaging est faite, avec des api pondues à la volée pour avoir une version 0 qui marche, chaque paquet peut évoluer dans son coin, l’important étant de bien répertorier les dépendances entre paquets pour que les modifs de l’un puissent être répercutées chez les autres.
À partir du moment où on a une liste des paquets+versions connus pour marcher entre eux, l’ensemble pourra évoluer petit à petit, exactement comme les paquets d’une distrib linux.
Essayez de monter un linux avec des paquets venant de versions très décalées dans le temps, et ce sera la cata, alors autant partir de ce constant et considérer qu’un paquet à le droit de ne plus être compatible avec un autre, tant que l’autre est mis au courant et qu’il garde donc la possibilité de se mettre à jour pour suivre ses voisins.Ça parait un peu bordélique comme ça, et c’est sur que les principes d’upgrade « qui se font tout seuls » comme c’est le cas actuellement risquent d’en prendre un sacré coup, mais je pense que l’idée vaut le coup d’être un peu creusée.
En résumé, et pour aller plus loin que le chantier initial du lab (réorg des répertoires, entre autres dans l’optique d’une usine à spips), pourquoi ne pas orienter le lab dans une « modularisation » des différentes fonctions du lab.
Un module est un paquet regroupant tout ce qui concerne une solution parmi d’autres sur un thème donné. Chaque paquet possède une liste de dépendences vers d’autres paquets versionnés (dépendance du type « il faut le paquet X, N <= version <= N’, ou Y M <= version <= M’ » …)
Une instance de spip est alors une liste de paquets et un ensemble de paramètres (connections bases, définition des tables spécifiques, config propre)
Un jeu de squelette peut être un paquet à part entière (squelettes par défaut, squelettes Eva …), dépendant lui même d’autre paquets (parce qu’un squelette qui utilise une boucle machin à besoin du paquet machin)L’important dans cette idée et de ne pas vouloir figer d’entrée de jeu des jeux de paquets initiaux et des points d’entrée. Les packages redhat ou debian ont évolué au fil du temps, certains ont fusionné, d’autres se sont scindés, et ça n’empèche pas linux de continuer à exister. C’est plus dans cet esprit là qu’il y a un intéret.
L’autre point important dans tout ça, c’est la possibilité de dispatcher le travail de maintenance : chaque paquet peut avoir son groupe de mainteneurs, qui travaille à son rythme, et évite ainsi le système un peu pyramidal actuel.
Là où ça se complique, c’est sur les points vraiment transversaux comme la doc et les traductions … là … j’ai pas d’idée précise.
Bon, assez causé … désolé d’avoir été aussi bavard, mais j’avais envie de faire le tour de cette idée histoire de lancer le débat.
La première partie est plus une discussion à lancer en liste, par contre, si l’idée du « spip en légo » a du succès, c’est plutôt sur le wiki qu’il faudra la débattre …À vous …
À+, Pif.
En fait, Pif viens tout juste de proposer les solutions de mon dernier message sur la liste :
-
Comment faire de SPIP un multi-site afin mutualiser le code SPIP entre plusieurs installations (cf. MultiSPIP), afin d’occuper moins despace disque et, dans le cas de beaucoup de petits sites SPIP hébergés sur un même serveur, le cache disque plus leger : C’est la solution Spip-Lego !
[plusieurs modules publics, un module privé, l’API principale, et la machine tourne déjà dans les gros traits] -
Quelle distrib survivra : Spip-dev ou Spip-Lab ?
Je vous préviens que je suivrai ce débat de très près…
P.S. : J’ai volontairement re-publié ce message dans la liste spip-dev afin que le debat puisse être le plus complet possible, avec l’avis « des 2 groupes ».