Why not ? cela permettrait de faire un résumé des épisodes.
Pour alimenter ce résumé je peux copier coller ici une réflexion que j'ai produite à l'interne du bureau des mainteneurs (attention- long-post)
Thierry RAFFIN (MIS SERVICES A DISTANCE ET MULTIMEDIA) a écrit :
y trop de points soulevés qui ne relevent pas de mon domaine, mais par contre, je peux répondre à celui ci :
la question de la couche PEAR reste posée ?
Pear en tant que tel n'est pas un soucis, c'est Pear-DB qui pose problème. Pear-DB est lent, c'est reconnu par les developpeur PEAR, et par les developpeur de SPIP-agora, la question ayant été soulevé il n'y a pas longtemps. Une petite recherche sur gmane permet de retrouver le post.
Spip utilisant genereusement la base SQL, il est indispensable que son accés soit optimum.
M.
Mathieu Lecarme a écrit :
Thierry RAFFIN (MIS SERVICES A DISTANCE ET MULTIMEDIA) a écrit :
y trop de points soulevés qui ne relevent pas de mon domaine, mais par contre, je peux répondre à celui ci :
la question de la couche PEAR reste posée ?
Pear en tant que tel n'est pas un soucis, c'est Pear-DB qui pose problème. Pear-DB est lent, c'est reconnu par les developpeur PEAR, et par les developpeur de SPIP-agora, la question ayant été soulevé il n'y a pas longtemps. Une petite recherche sur gmane permet de retrouver le post.
Spip utilisant genereusement la base SQL, il est indispensable que son accés soit optimum.
Donc se repose la question :
- soit de ADOdb (http://adodb.sourceforge.net/)
- soit d'un module par base de données spécifique (mais je crois bien que c'est un des modes de fonctionnement de ADOdb)
Jacques
Quelqu'un voudrait m'expliquer pourquoi il faut une couche d'abstraction de la DB ?
Y a t i l une bonne raison de désespérer que du SQL mis au plus petit dénominateur commun
entre MySQL, PostgresQL et SQLite puisse suffire ?
Minh
Jacques PYRAT a écrit :
Mathieu Lecarme a écrit :
Thierry RAFFIN (MIS SERVICES A DISTANCE ET MULTIMEDIA) a écrit :
y trop de points soulevés qui ne relevent pas de mon domaine, mais par contre, je peux répondre à celui ci :
la question de la couche PEAR reste posée ?
Pear en tant que tel n'est pas un soucis, c'est Pear-DB qui pose problème. Pear-DB est lent, c'est reconnu par les developpeur PEAR, et par les developpeur de SPIP-agora, la question ayant été soulevé il n'y a pas longtemps. Une petite recherche sur gmane permet de retrouver le post.
Spip utilisant genereusement la base SQL, il est indispensable que son accés soit optimum.
Donc se repose la question :
- soit de ADOdb (http://adodb.sourceforge.net/)
- soit d'un module par base de données spécifique (mais je crois bien que c'est un des modes de fonctionnement de ADOdb)
adodb à le bon gout d'emuler des trucs SQL qui simplifie la vie (comme le LIMIT de MySQL) et d'avoir une version en PHP pour la compatibilité, et une version en C pour la vitesse.
Ils se vantent aussi davoir l'abstraction la plus rapide.
Ensuite Spip a une tradition du "not invented here".
Si j'ai tout suivi, le nouveau compilo, avec sa machine à pondre le SQL devrait s'occuper de l'abstraction SQL.
M.
Minh Ha Duong a écrit :
Quelqu'un voudrait m'expliquer pourquoi il faut une couche d'abstraction de la DB ?
1 code, n bases.
Y a t i l une bonne raison de désespérer que du SQL mis au plus petit dénominateur commun
entre MySQL, PostgresQL et SQLite puisse suffire ?Minh
il y a des trucs de bases qui ne font pas partie PPCD, comme récuperer l'id du dernier élément inséré.
La couche d'abstraction permet de ne pas utiliser un SQL trop castré et de ne pas trop troubler les performances.
Ce qui peut être ultime avec le nouveau compilo et l'abstraction, c'est d'avoir une base qui gere les vues (Postgres, SQLite ...) ce qui simplifie ENORMEMENT l'utilisation des squelettes, plus de jointures bizzares, de gruges ésotérique, le compilo fait des SELECT * dans la vue, et ça, il le fait trés bien. Comme ça, tu as un site spécifique à une base, mais le produit Spip reste neutre.
M.
Voila quelques éléments, que je n'avais pas alors que je m'efforce de suivre
les 2 listes, qui expliquent cette volonté politique soudaine mais qui ne
rassurent pas vraiment quant au mode de prise de décision ...
Je m'interroge sur la notion de moyen terme et long terme (l'été prochain
pour moi, c'est plutot court / moyen ...) et sur l'investissement (tant
politique que financier) réel qui suivra.
Et surtout, je trouve que les choses se font dans un ordre bizarre.
Pour ma part, j'attend que "spip-core" annonce le perimetre retenu pour la
1.8 et ses orientations pour la suite.
J'ai peut etre raté des épisodes, mais pour le moment mon niveau
d'information est le suivant :
- Emmanuel a un paquet d'amélioration sous le coude (ca doit commencer à
etre confortable 
), toutes ne seront pas sur la 1.8, mais le nouveau
compilo va de toute facon dans le sens de la modularisation (multi base,
multi spip, multi syntaxe)
- Fil est pour un recentrage de Spip sur un noyau fonctionnellement limité
mais facilement extensible. Le nouveau découpage du code du compilo est deja
en soit une modularisation, mais il reste beaucoup de dépendances à alleger
- Arno* n'a rien dit la dessus si ce n'est qu'il faut etre un peu réaliste
et penser d'abord à la 1.8, mais il nous a livré un premier jet de plugin
qui ouvre deja un grand nombre de possibilité et me laisse donc penser que
le principe l'interesse.
- Antoine a monté Spip-lab, entre autre, pour que ce type de projet puisse
voir le jour ...
Pour l'instant, nous n'avons pas eu vraiment d'orientations claires pour les
très justes raisons evoquées par Arno* : priorité 1.8.
Maintenant, en admettant que tout le monde soit emballé à l'idée lancer une
v2 avec des objectifs communs (?), soyons réaliste : Spip vient d'etre en
grande partie recodé (et bien recoder) et je crois qu'il n'est pas question
aujourd'hui de "recodage".
Il est question de "découpage" en essayant de limiter les interdépendances à
des "interfaces" clairement spécifiées (API clair pour chaque module)
Le premier interet pour Spip (ben oui au fait, il faudrait peut etre se la
poser la question de l'interet de Spip ...) est bien sur la maintenabilité.
Tous les ajouts fonctionnels recents donnent beaucoup d'inertie au projet et
allongent les cycles des versions.
Cette modularisation permettra de déléguer plus facilement la gestion de
briques fonctionnelles interchangeables, mais c'est aussi un grand coup de
boost aux contributions, une ouverture à d'autres domaines fonctionnels ...
Le modele objet permet effectivement ca naturellement mais n'est pas
indispensable, loin de la (l'approche installation de MOD me plait bien, ca
permet de garder l'instalaltion en 5 clics avec les options Spip-dist
pré-cochées et de "monter" un spip optimisé pour telle ou telle
utilisation).
Aujourd'hui, l'urgence me semble etre à la documentation de la 1.8.
Les remarques de JLuc viennent à mon sens surtout de ce manque de doc car je
crois au contraire que la nouvelle interface et le nouveau compilo apportent
de nouvelles possibilités sans rien enlever à la simplicité d'installation
et d'utilisation (voire meme, une interface plus ergonomique et des
facilités de debug qui rendent cette version encore plus accessible).
Viendra ensuite l'urgence de la "roadmap" comme on dit (je suis demandeur
mais j'ai conscience que les journées ne font que 24h et que les TODO se
remplissent plus vite qu'elles ne se vident).
Mais pour qu'elle puisse voir le jour, il faudrait deja avoir bouclé cette
1.8 et que les fonctionnalités commencent à etre proposées sous forme de
plugin, MOD ou autre, car il y aura forcement differentes stratégies en
fonction du code à "externaliser".
Je serai donc direct : le projet SPIP DGA (ou autre, mais ca me parait le
plus logique) peut il financer cette documentation ?
Ca serait la un vrai apport à la communauté Spip et une preuve de "bonne
volonté", ca ferait avancer les choses et les principaux interessés auraient
l'esprit un peu plus libre pour reflechir à l'avenir.
Qu'en dites vous ?
@++
Salut,
Deux choses:
1. merci de ne pas crossposter. Cela rend les discussions impossibles à
suivre et ça ne fait qu'augmenter le potentiel trollifère (déjà assez
grand en soi).
2. merci d'essayer de synthétiser les choses de façon concise. Je n'ai pas
le temps de lire des messages tels quel celui ci-dessous, et je ne pense
pas être le seul.
Cordialement
Antoine.
Why not ? cela permettrait de faire un résumé des épisodes.
Pour alimenter ce résumé je peux copier coller ici une réflexion que j'ai
produite à l'interne du bureau des mainteneurs (attention- long-post)
[etc.]
Stephane LAURENT a écrit :
Voila quelques éléments, que je n'avais pas alors que je m'efforce de suivre
les 2 listes, qui expliquent cette volonté politique soudaine mais qui ne
rassurent pas vraiment quant au mode de prise de décision ...
Je m'interroge sur la notion de moyen terme et long terme (l'été prochain
pour moi, c'est plutot court / moyen ...) et sur l'investissement (tant
politique que financier) réel qui suivra.Et surtout, je trouve que les choses se font dans un ordre bizarre.
Pour ma part, j'attend que "spip-core" annonce le perimetre retenu pour la
1.8 et ses orientations pour la suite.J'ai peut etre raté des épisodes, mais pour le moment mon niveau
d'information est le suivant :
- Emmanuel a un paquet d'amélioration sous le coude (ca doit commencer à
etre confortable), toutes ne seront pas sur la 1.8, mais le nouveau
compilo va de toute facon dans le sens de la modularisation (multi base,
multi spip, multi syntaxe)
c'est quoi le multi syntaxe?
- Fil est pour un recentrage de Spip sur un noyau fonctionnellement limité
mais facilement extensible. Le nouveau découpage du code du compilo est deja
en soit une modularisation, mais il reste beaucoup de dépendances à alleger
- Arno* n'a rien dit la dessus si ce n'est qu'il faut etre un peu réaliste
et penser d'abord à la 1.8, mais il nous a livré un premier jet de plugin
qui ouvre deja un grand nombre de possibilité et me laisse donc penser que
le principe l'interesse.
- Antoine a monté Spip-lab, entre autre, pour que ce type de projet puisse
voir le jour ...Pour l'instant, nous n'avons pas eu vraiment d'orientations claires pour les
très justes raisons evoquées par Arno* : priorité 1.8.Maintenant, en admettant que tout le monde soit emballé à l'idée lancer une
v2 avec des objectifs communs (?), soyons réaliste : Spip vient d'etre en
grande partie recodé (et bien recoder) et je crois qu'il n'est pas question
aujourd'hui de "recodage".
Il est question de "découpage" en essayant de limiter les interdépendances à
des "interfaces" clairement spécifiées (API clair pour chaque module)
Le premier interet pour Spip (ben oui au fait, il faudrait peut etre se la
poser la question de l'interet de Spip ...) est bien sur la maintenabilité.
Tous les ajouts fonctionnels recents donnent beaucoup d'inertie au projet et
allongent les cycles des versions.
Cette modularisation permettra de déléguer plus facilement la gestion de
briques fonctionnelles interchangeables, mais c'est aussi un grand coup de
boost aux contributions, une ouverture à d'autres domaines fonctionnels ...
Le modele objet permet effectivement ca naturellement mais n'est pas
indispensable, loin de la (l'approche installation de MOD me plait bien, ca
permet de garder l'instalaltion en 5 clics avec les options Spip-dist
pré-cochées et de "monter" un spip optimisé pour telle ou telle
utilisation).Aujourd'hui, l'urgence me semble etre à la documentation de la 1.8.
coté code ou coté utilisateur?
Les remarques de JLuc viennent à mon sens surtout de ce manque de doc car je
crois au contraire que la nouvelle interface et le nouveau compilo apportent
de nouvelles possibilités sans rien enlever à la simplicité d'installation
et d'utilisation (voire meme, une interface plus ergonomique et des
facilités de debug qui rendent cette version encore plus accessible).Viendra ensuite l'urgence de la "roadmap" comme on dit (je suis demandeur
mais j'ai conscience que les journées ne font que 24h et que les TODO se
remplissent plus vite qu'elles ne se vident).
Mais pour qu'elle puisse voir le jour, il faudrait deja avoir bouclé cette
1.8 et que les fonctionnalités commencent à etre proposées sous forme de
plugin, MOD ou autre, car il y aura forcement differentes stratégies en
fonction du code à "externaliser".Je serai donc direct : le projet SPIP DGA (ou autre, mais ca me parait le
plus logique) peut il financer cette documentation ?
tu veux que quoi soit documenté? la syntaxe des squelettes du nouveau compilo, le code de Spip, le guide utilisateur?
Ca serait la un vrai apport à la communauté Spip et une preuve de "bonne
volonté", ca ferait avancer les choses et les principaux interessés auraient
l'esprit un peu plus libre pour reflechir à l'avenir.
je crains ne pas comprendre.
M.
Mathieu Lecarme a écrit :
Stephane LAURENT a écrit :
- Emmanuel a un paquet d'amélioration sous le coude (ca doit commencer à
etre confortable
compilo va de toute facon dans le sens de la modularisation (multi base,
multi spip, multi syntaxe)c'est quoi le multi syntaxe?
C'est un élément qu'Emmanuel a sous le coude : pour changer le langage des boucles SPIP et le rendre (par exemple) conforme XML.
Intérêt ? Nvu !
Jacques
c'est quoi le multi syntaxe?
Le compilateur est relativement autonome et Emmanuel a deja evoqué la
possibilité d'en proposer d'autres version, dont une syntaxe de boucle en
XML
coté code ou coté utilisateur?
Les deux !
La doc utilisateur est necessaire à la sortie de la 1.8 et la documentation
du code l'est tout autant surtout si on veut que beaucoup de gens mettent le
nez dedans.
Mais la documentation du code n'est pas forcement à faire completement, cela
dependra des orientations de Spip.
tu veux que quoi soit documenté? la syntaxe des squelettes du nouveau
compilo, le code de Spip, le guide utilisateur?
Que la doc de Spip.net soit mise à jour serait deja un boulot enorme.
Ca me parait le plus urgent.
Après, coté code, c'est plutot bien commenté mais il manque un descriptif
general de l'architecture et des pseudo package actuel, et sans doute
quelques contrib de doc particulieres et autres exemples de trucs tordus.
je crains ne pas comprendre.
Je dis juste que Antoine, Arno*, Fil et Emmanuel ont pour l'instant d'autres
priorité et que les decharger un peu serait "rendre service" à la
communauté.
Je dis egalement que Spip, c'est leur jouet, ils en fnt ce qu'il veulent et
que pour l'instant, on ne sait pas exactement ce qu'ils veulent meme si on a
déja quelques elements.
C'est tout.
Jacques PYRAT a écrit :
Mathieu Lecarme a écrit :
Stephane LAURENT a écrit :
- Emmanuel a un paquet d'amélioration sous le coude (ca doit commencer à
etre confortable
compilo va de toute facon dans le sens de la modularisation (multi base,
multi spip, multi syntaxe)c'est quoi le multi syntaxe?
C'est un élément qu'Emmanuel a sous le coude : pour changer le langage des boucles SPIP et le rendre (par exemple) conforme XML.
Intérêt ? Nvu !
nvu il peut faire un effort aussi, c'est un outil parmi tant d'autres.
Si ça permet davoir des trucs moins moche que <//B_toto> c'est effectivement une bonne idée.
M.
Mathieu Lecarme a écrit :
Jacques PYRAT a écrit :
C'est un élément qu'Emmanuel a sous le coude : pour changer le langage des boucles SPIP et le rendre (par exemple) conforme XML.
Intérêt ? Nvu !nvu il peut faire un effort aussi, c'est un outil parmi tant d'autres.
Je suis d'accord avec toi, mais
1. Il est gratuit
2. Il produit du code conforme
3. Il n'est pas terminé
Si ça permet davoir des trucs moins moche que <//B_toto> c'est effectivement une bonne idée.
À suivre...
Jacques
coté code ou coté utilisateur?
Les deux !
La doc utilisateur est necessaire à la sortie de la 1.8 et la documentation
du code l'est tout autant surtout si on veut que beaucoup de gens mettent le
nez dedans.
Mais la documentation du code n'est pas forcement à faire completement, cela
dependra des orientations de Spip.
ya des demarrage dans le lab, sur le wiki, pour savoir par où attraper le code. Mais ça ne remplacera pas du phpdoc.
tu veux que quoi soit documenté? la syntaxe des squelettes du nouveau
compilo, le code de Spip, le guide utilisateur?
Que la doc de Spip.net soit mise à jour serait deja un boulot enorme.
Ca me parait le plus urgent.
Après, coté code, c'est plutot bien commenté
euh...
mais il manque un descriptif
general de l'architecture et des pseudo package actuel, et sans doute
quelques contrib de doc particulieres et autres exemples de trucs tordus.je crains ne pas comprendre.
Je dis juste que Antoine, Arno*, Fil et Emmanuel ont pour l'instant d'autres
priorité et que les decharger un peu serait "rendre service" à la
communauté.
C'est rigolo, je me fait troller par ce que je poste avec 2 mails différents (entreprise et perso), et par ce qu'une entreprise ose faire du business avec Spip, et ensuite, il faut "rendre service"?
Je pense déja le faire, avec de la doc et du code.
Je dis egalement que Spip, c'est leur jouet, ils en fnt ce qu'il veulent et
que pour l'instant, on ne sait pas exactement ce qu'ils veulent meme si on a
déja quelques elements.
C'est tout.
la doc du code, c'est dans le code. Je veux commenter un bout, envoyer le diff, mais faut que ce soit integré. C'est top casse couille la doc, si c'est pas utilisé, ce n'est pas la peine. Ce n'est pas comme une contrib.
M.
ya des demarrage dans le lab, sur le wiki, pour savoir par où attraper
le code. Mais ça ne remplacera pas du phpdoc.
Les wikis (contrib et lab) et/ou phpdoc, c'est bien pour les developpeurs,
je crois que JLuc a raison de dire qu'il faut veiller à rendre l'outil
accessible au plus grand nombre.
Spip.net est la reference, ainsi que l'aide en ligne, c'est pour ca que je
trouve ca assez prioritaire pour sortir la 1.8
Après, coté code, c'est plutot bien commenté
euh...
Ben t'as pas vu ce que je fais alors !
non, je veux dire par la qu'un developpeur retrouve facilement ses petits
donc peut faire des contribs et de la doc grand public
C'est rigolo, je me fait troller par ce que je poste avec 2 mails
différents (entreprise et perso), et par ce qu'une entreprise ose faire
du business avec Spip, et ensuite, il faut "rendre service"?
Je pense déja le faire, avec de la doc et du code.
la doc du code, c'est dans le code. Je veux commenter un bout, envoyer
le diff, mais faut que ce soit integré. C'est top casse couille la doc,
si c'est pas utilisé, ce n'est pas la peine. Ce n'est pas comme une
contrib.
Allons, allons, tu ne t'es pas fait "troller", tu t'es fait jeté par
Emmanuel qui a passer du temps à repondre à tes question sans savoir que tu
travaillais pour une boite en train de "vendre" du Spip. Il n'y avait pas de
mauvaises intention derrière et tout le monde s'est calmé, c'etait juste un
malentendu. derriere un grand troll s'est relancé sur les rapports
Entreprise / SSII / SSLL / Projet libre, mais si les choses pouvaient etre
faciles, il n'y aurait pas une GPL v3 en préparation.
Ca n'est un troll que parcque cette discussion n'est pas forcement à sa
place ici, mais ce genre de débats aide au moins à cerner les differents
intervenants et à eviter de se vendre du "gagnant-gagnant" entre nous.
Coté doc, bien sur que c'est chiant et c'est bien pour ca que personne ici
ne s'est jeté dessus !
Mais il faudra bien la faire. Si ce n'est pas une société qui le fait, ca
sera fait quand meme, mais ca prendra plus de temps et demandera du boulot,
au moins d'organisation, aux "spip-core".
C'est pour ca que ca me parait interessant qu'un "client" achete la
rédaction de cette doc (je veux bien la faire pour 600?/j, mais j'espere que
vous etes moins cher !)
Et quand je parle de preuve de bonnes intention, soyons clair, je parle du
client, pas du prestataire et encore moins des employés du préstataire.
@++
Stephane LAURENT a écrit :
ya des demarrage dans le lab, sur le wiki, pour savoir par où attraper
le code. Mais ça ne remplacera pas du phpdoc.
Les wikis (contrib et lab) et/ou phpdoc, c'est bien pour les developpeurs,
je crois que JLuc a raison de dire qu'il faut veiller à rendre l'outil
accessible au plus grand nombre.
Spip.net est la reference, ainsi que l'aide en ligne, c'est pour ca que je
trouve ca assez prioritaire pour sortir la 1.8Après, coté code, c'est plutot bien commenté
euh...
Ben t'as pas vu ce que je fais alors !
non, je veux dire par la qu'un developpeur retrouve facilement ses petits
donc peut faire des contribs et de la doc grand public
Déja, un emplacement officiel (spip, spip-lab, spip-contrib ...) ça aiderait pas mal.
Ensuite, je me repete, mais en dehors de phpdoc, je ne vois pas trop comment faire, et surtout maintenir à jour.
Il y a quelques fonctions qui semble orpheline, ou dont l'utilité n'est pas évidente, comme spip_query vs spip_query_db .
Il y a aussi l'usage des variables globales qui est difficile à documenter.
M.
Bonsoir,
Je préfère corriger qqs incorrections ou interprétations hasardeuses
Par ailleurs cette situation de "fork" de SPIP Agora est rendue plus complexe encore avec l'émergence récente d'une nouvelle opération de commande publique appuyée sur le noyau de la version 1.8 de SPIP (en préparation) : celle de la DGA.
Si par commande publique tu entends une réponse à un appel d'offre,
alors oui, l'instance de spip que nous sommes amenés à développer pour
la DGA est une commande publique.
Il ne faut pas le voir autrement.
Le terme commande publique me parait avoir un autre sens dans le cadre
du projet Agora ;).
Celle-ci devait initialement être développée sur la base Spip agora mais des inquiétudes par rapport aux pb de performance rencontrés au début par SPIP Agora pour des sites volumineux ont conduit à choisir finalement la version l .8 de spip. Cette version répond à des demandes spécifiques - non développées dans la vorsion 1.8 , mais pour partie présentes dans SPIP Agora. Cette version est développée par Linagora, société concurrente de Clever Age mais qui a réussi quant à elle à mobiliser l'un des mousquetaire de Spip pour mettre au point ces fonctionnalités. Cependant cette utilisation d’un des développeurs essentiels de Spip dans le cadre d’une commande publique ne garantit pas pour autant aujourd hui que ces fonctionnalités soient finalement toutes reprises et intégrées dans la V1.8 de Spip dont la date do sortie et le périmètre fonctionnel restent indéterminés. Ceci risque d'aboutir à court terme à la coexistence
* d’une version do Spip Agora optimisée dans ses fonctionnalité et ses performances, mais incompatible (PEAR et noyau î.7 ) avec la V1.8
* d’une version 1.8 de S Pip? améliorée des fonctionnalités de SPIP Agora et compatible pour le moment avec la V1.8 de Spip (mais pour combien de temps ?)
* et enfin de la version officielle et historique de SPIP
Si SPIP a été choisit "au détriment d'agora" même si nous avions vendu
une presta avec agora initiallement, c'est pas tant pour des problèmes
de performances que plutot par les possibilités offertes par le nouveau
compilateur, qui nous retire une sacré épine du pied 
Les fonctionnalités que nous avons été amenés à développer pour le
compte de la DGA ont vocation à être redistribuées et pour certaines
intégrées (sans garantie de date mais avec au moins un accord de
principe sur l'intéret de ses contrib et certaines comme la notification
ou le moteur de formulaires sont déjà dans spip lab).
La version qui sera livrée à la DGA sera "SPIP Compliant" au maximum
afin de permettre de suivre les évolutions de spip de la façon la plus
simple possible. Cela ne se fera peut être pas commme une mise à jour
classique de spip en trois coup de cuillères à pot mais l'idée est
d'arriver au plus proche de ce stade...
Spip DGA n'a pas vocation de devenir une sorte d'Agora V2, en tous cas,
je ne me place pas dans cette objectif. Notre objectif est et reste la
compatibilité maximale avec Spip et une mise à disposition des
fonctionnalité développées (hors développements ultra spécifiques).
Renoncer à cette direction du « merge » par le refus de la communauté orginelle de SPIP peut-il néanmoins orienter et conduire à une stratégie d’une autre « alliance » avec la DGA pour un « merge » cette fois V1.8 DGA / V1.3 SPIP Agora, pour autant que le jeu en vaille la chandelle (pas de perte ou plutôt même gains fonctionnel ou de performance potentiel, et une économie dans une maintenance d’une version publique de SPIP optimisée et recallée sur les avancées de la V1.8 de SPIP) ? Ce qui pourrait soutendre les (re)développements nécessaires à un tel projet pourrait être le projet « prodig » d’inter-opérabilité des sites publics au niveau d’une syndication maîtrisée des contenus (appuyé sur un module « php » renforcé initié pour le comarquage Copéria ? appuyé sur la console d’import/export SPIP : SIEPS ? autre produit à identifier ou définir ?). En tout état de cause un cahier des charges est à définir pour trouver la meilleure formule.
En cas d’échec de cette voie là (alliance SPIP Agora / SPIP DGA) la question de la couche PEAR reste posée ? mais les termes de cette question peuvent-ils alors modifier la réponse ? faut-il penser que le coût de cette suppression envisagée pour refondre SPIP Agora et SPIP, deviendrait trop important par rapport à ce qui pourrait être gagné ? une simple optimisation du code et un module d’installation ne serait-il pas suffisants ? Cette perspective doit-elle même constituer l’horizon premier de SPIP Agora : suivre son chemin sans s’embarrasser des problèmes de compatibilités avec SPIP ? Il faudrait alors se concentrer sur la définition d’une « road-map » totalement spécifique à SPIP Agora dans la reconnaissance d’un « fork » irrémédiable. A partir de là une action de définition et de promotion d’une V2 de SPIP Agora optimisée intégrant le moteur de syndication deviendrait une priorité.
Attention, à ce jour et comme je l'ai dit : cette voie là n'existe pas
pour moi ou en tout cas n'a pas véritablement vocation d'être. Notre
objectif reste la compatibilité Spip et même si on a backporté certaines
fonctionnalités d'Agora parce que nous en avions besoin, il ne faut pas
se tromper de cible ou voir dans nos intentions plus qu'on ne pourrait y
voir.
En outre, ces deux projets sont parties sur des bases différentes, je
vois mal comment on pourrait les faire rejoindre en tous cas à court
terme.
Spip DGA est peut être un entre deux entre spip 'officiel' et spip agora
mais a vocation de rester du coté de spip et c'est bien notre engagement
passé avec le client. On ne vise pas le fork intermédiaire qui pourrait
se faire réconcilier tout le monde... (enfin ca fait pas partie du
projet, ni de mon horizon à court terme )
Nicolas
Hello,
la licence qu'on a choisie n'est pas le seul code génétique de l'identité de
SPIP et de sa communauté, et ce n'est pas la licence qui a "fait" SPIP toute
seule. Or depuis quelque temps, tout le reste est allègrement piétiné par
une horde de consultants déchaînés qui inviquent à tout bout de champ la
GPL, ce qui commence à me fatiguer plus qu'il n'est raisonnable.
Quelques rappels donc, qui auraient dû aller sans dire, mais au point où
nous en sommes, malheureusement :
- Si on pouvait éviter que la version de Linagora soit surnommée "SPIP DGA",
l'air serait probablement un peu plus respirable. Ce logiciel n'est pas
seulement sous GPL, il est aussi non-sexiste, respectueux de toutes les
cultures, et n'a pas spécialement vocation à devenir militariste.
- "faire financer la doc". Il me semble qu'on a déjà répondu 200 fois à
cette question, mais elle revient sans cesse, toujours portée par des
consultants de tout poil.
Le projet SPIP s'est historiquement construit sur la base d'une méfiance
vis-à-vis de l'argent, et le jour où ceux qui bossent vraiment souhaiteront
que ça change, ils le feront savoir -- mais je ne crois pas que ce jour soit
venu, en tout cas du côté "spip-core".
D'ici là, si la doc ne vous convient pas, trouvez un moment pour y
participer gratuitement ou en vous débrouillant comme vous le pouvez, mais
ne croyez pas que le problème sera résolu avec une subvention quelconque. Il
faut du boulot de passionné, c'est tout, et ça n'a pas de prix.
- Enfin, la question du fork : je ne doute pas un seul instant que les
ingénieurs informaticiens dont c'est le travail sont capables de gérer des
projets autrement plus complexes que "des versions patchées de SPIP"...
cette agitation autour des forks ou pas forks est donc totalement minable.
Pour utiliser des bricolages réalisés par un petit groupe de copains qui ont
appris à programmer chemin faisant, il vous faudrait des dizaines de
millions d'euros, des pelletées d'équipes de dizaines d'ingénieurs et des
heures de réunion de comités de pilotage ? Soyons sérieux...
- Ce qui se produit en ce moment, c'est que le volume de troll engendré par
les discussions entre consultants et businessmen est en train de dégoûter et
de détourner les utilisateurs et contributeurs normaux (ceux qui ne parlent
pas à longueur de journée de millions de patates, de fric ou de contrats).
Il n'y a qu'à voir qui ose encore s'exprimer sur la liste spip-dev, pour
constater les dégâts. Merci.
PS: amis consultants, si le fait que tour à tour Arno*, Emmanuel, Antoine et
moi nous sentions obligés de râler ou de dire "stop" ne vous fait rien,
on modérera la liste en bloquant d'entrée de jeu tout message contenant
les mots-clés "patates", "euros", "(lin)agora", "dga", "cahier des
charges", "financ*", etc. Ca alourdira encore notre charge de corvée
spipienne, ce qui n'est pas forcément dans votre intérêt.
PPS: ce mail n'appelle pas de réponse, c'est bon.
-- Fil
Jacques PYRAT a écrit :
Mathieu Lecarme a écrit :
Stephane LAURENT a écrit :
- Emmanuel a un paquet d'amélioration sous le coude (ca doit commencer à
etre confortable
compilo va de toute facon dans le sens de la modularisation (multi base,
multi spip, multi syntaxe)c'est quoi le multi syntaxe?
C'est un élément qu'Emmanuel a sous le coude : pour changer le langage des boucles SPIP et le rendre (par exemple) conforme XML.
Intérêt ? Nvu !
et même pour DW...
:)
A bientôt,
^Fabrice^^
Ce qui peut être ultime avec le nouveau compilo et l'abstraction, c'est
d'avoir une base qui gere les vues (Postgres, SQLite ...) ce qui
simplifie ENORMEMENT l'utilisation des squelettes, plus de jointures
bizzares, de gruges ésotérique, le compilo fait des SELECT * dans la
vue, et ça, il le fait trés bien. Comme ça, tu as un site spécifique à
une base, mais le produit Spip reste neutre.
C'est la principale raison qui ma poussé à commencer le portage de SPIP 1.7 sous PG.
Même si je l'avoue je n'exploite pas encore cette possibilité.
Mon but est d'avoir ton mes softs sous PG et d'utiliser des vues pour les bases communes.
Cordialement,
Jean-Gérard Pailloncy