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)

***************
SPIP / SPIP Agora

Reprenons un peu l'histoire de ces derniers mois pour savoir quel parti prendre entre le "merge" et le
"fork" ?

Par le fait de la date de décision du projet SPIP Agora a été développé sur une version 1.7 de SPIP. Ce
développement pris en charge par la société Clever Age sur commande publique du SIG s'est fait sans
véritable concertation et implication de la communauté de SPIP et en particulier de ses fondateurs.
Ceci a introduit du fait aussi sans doute d'autres événements antérieurs, une accentuation d'une
forme de méfiance idéologique de la communauté avec une commande émanent de l'administration
centrale de l'état. Les choix techniques fait par Clever Age pour répondre au cahier des charges du SIG,
par la complexité introduite dans l'architecture SPIP Agora (en particulier l'abstraction de la base
de donnée avec la couche PEAR) et dans les techniques de développement (l'incorporation forte de la
programmation orientée objet), n'ont pas contribué à "séduire" la communauté. Les tentatives
"tardives" de dialogue au moment de la sortie de SPIP Agora pour rallier une communauté à l'acceptation
ou à l'intégration de SPIP Agora se sont soldées par un dialogue de sourds, une critique assez forte de
la démarche et des choix structurants de SPIP Agora. Les dernières tentatives semblent être un rejet
manifeste de tout dialogue.

Cependant dans le même temps des interrogations se font jour au sein du bureau des mainteneurs constitué
à la rentrée de septembre 2004 suite à la promotion de SPIP Agora à l'Université de la communication
de Hourtin :

    * les problèmes de performances rencontrés en plusieurs endroits dans l'utilisation de SPIP Agora
amènent à se poser certaines questions quant aux développements réalisés. Que doivent ces pb
rencontrés tant en back office (BO) qu'en front office (FO), aux choix de développement (couche PEAR en
particulier) ? Ne sont-ils pas dû aussi à la capacité native du noyau de SPIP (basé sur la 1.7) à
traiter des sites volumineux en rubriques/articles, en nombres de contributeurs (ayant des droits
restreints dans un système de work flow enrichi à 4 niveaux) ? 

Ces questions importantes pour la promotion et la diffusion de SPIP agora (complexité d'installation et
pb de performance) aboutissent à une série d'action mobilisant les utilisateurs et développeurs de
SPIP pour résoudre ces problèmes de performance. D'abord l'ANPE qui règle en large partie les pb du
côté du BO, puis le SIG avec Clever Age pour permettre la sortie en production du site du premier
ministre, puis à nouveau Clever Age pour le Ministère des affaires étrangères (MAE) dont le site est
particulièrement volumineux. Dans le même temps il apparait que chacun des utilisateurs de SPIP Agora
utilise une version de SPIP Agora adaptée à ses besoins et différente des versions distribuées (1.1,
1.2, 1.21) sur le site agora.gouv.fr. Plusieurs décisions ont donc été récemment prises par le
bureau des mainteneurs :

    * finaliser les développements de la version de la MAE qui devrait permettre de régler au mieux les pb de
performance dans le cadre du noyau de la 1.7 de SPIP
    * assurer un audit de code de cette version pour vérifier que tous les gains de performance ont bien été réalisés.
    * réaliser une description des fonctionnalités propres à chacune des versions en production (SIG /
ANPE / MAE / autres ?) et faire un diff technique de ces versions
    * s'accorder sur l'intégration des spécificités des versions du SIG et de l'ANPE dans une version
stabilisée de SPIP Agora à distribuer, baptisée V1.3. (en remplacement des versions actuellement distribuées)
    * actualiser sur le site agora.gouv.fr la documentation de cette version 1.3
    * supprimer dans le code de cette version les codes remplacés d'origine de SPIP du fait d'une différence
devenue trop importante avec l'évolution de SPIP avec le nouveau compilateur au coeur de la V1.8 

Cette situation conduit donc à deux produits parents SPIP 1.8 et SPIP Agora 1.3 incompatibles.

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.

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 

Cette situation peut vite apparaître dommageable pour tous. Pour qui précisément ? Pourquoi ?

    * Pour les utilisateurs qui risquent fort d’avoir du mal à s'y retrouver, ou à faire des choix
draconniens entre une garantie de maintenance et une richesse fonctionnelle (à documenter précisément)
    * pour la communauté du libre qui va voir ses forces se disperser sur le développement de nouvelles
fonctionnalités sur des projets parents concurrents
    * Pour les institutions qui vont perdre en capacités de maintenance évolutives
    * pour Les contribuables qui vont payer ces développements qui ne pourront être reversés gue dans des
Communautés restreintes dont on mesure mal la taille (avec cette interrogation du positionnement des
collectivités locales entre ces produits "concurrents" . 

Une certaine rationalité commanderait de retrouver les voies du « merge ». Mais est-ce encore possible
et à quelles conditions ? Et alors si cela s’avère possible, est-ce véritablement souhaitable ? Sur
la question de la possibilité il faut distinguer deux plans sans doute : la faisabilité technique et la
volonté de l’ensemble des acteurs d’y parvenir. Techniquement on peut sans doute dire que c’est
possible (même si cela doit avoir un coût). La version 1.8 de la DGA en dessine d’ailleurs la voie
d’une certaine manière (reste à vérifier que cette version ne rencontrera pas les problèmes de
performance de SPIP Agora, mais elle pourrait alors sans doute bénéficier des avancées de SPIP Agora
en ce domaine par retour des choses). Mais la vraie difficulté est sans doute plutôt du « vouloir » : la
communauté SPIP est-elle prête à bouger par rapport à ses débats actuels ? Sa difficulté à
accepter d’intégrer toutes les fonctionnalités de la version de la DGA, au moins à court terme, peut
soulever des doutes à ce niveau. L’idée de stabiliser le noyau (encore instable) de la V1.8 apparaît
encore dominante dans les débats, même si une pression des utilisateurs existe pour introduire le plus
vite possible (et donc à la sortie de la V1.8) des fonctionnalités utiles aux utilisateurs (car les
avancées techniques liées au nouveau compilateur sont pour l’essentiel « invisibles »). Sans
doute cette réticence serait-elle encore plus grande avec le projet de réincorporer dans SPIP le work
flow à 4 niveaux (qui apparaît à de nombreux SPI Peurs? comme une « usine à gaz » du contrôle
administratif de la création (vaste débat...plus idéologique que technique car cette
fonctionnalité utile et nécessaire pour introduire SPIP dans certaines organisations de production
des contenus, est aujourd’hui bien stabilisée). Quand bien même cela serait envisageable
resterait de toute manière à entreprendre comme cela a été fait déjà en partie au sein du projet SPIP
Agora (mais plus encore dans la SPIP DGA) la suppression de la couche PEAR pour rendre
acceptable-possible le merge. Mais cette suppression qui faciliterait sans doute le processus
d’installation de SPIP Agora (même si on peut imaginer un module d’installation mieux intégré
SPIP Agora PEAR…) aurait peut être des répercussions sur le développement des fonctionnalités de
SPIP (quid en particulier de l’abstraction de la base de données, et surtout de la gestion de cache par
rapport aux fonctions de personnalisation – cela reste à étudier de plus près…) Aller dans cette
direction (de la suppression de PEAR) peut permettre aussi de faire bénéficier SPIP agora des apports
au niveau du compilateur et des évolutions de SPIP qu’il permet. Mais lorsqu’on dit cela que dit-on
précisément au-delà d’une garantie (importante) de compatibilité et d’une « réunification
» de la communauté (intéressante) ? qu’est-ce que ce nouveau compilateur apporte-t-il ou peut-il
apporter à SPIP (fonctionnalités ? performances ?). Il faudrait détailler ici avec les développeurs.

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é.

Thierry RAFFIN
Responsable de la mission portail anpe.fr

-----Original Message-----
From:	spip-dev-bounces <at> rezo.net on behalf of Christian Lefebvre
Sent:	jeu. 09/12/2004 09:22
To:	spip-dev <at> rezo.net
Cc:	
Subject:	[spip-dev] Re: [Agora-generale] Avenir, avenir....
On Thu, 2004-12-09 at 09:05, Thierry RAFFIN (MIS SERVICES A DISTANCE ET
MULTIMEDIA) wrote:
> (je post ici sur agora-générale où la discussion s'est amorcée et sur
> spip-dev que j'ai un peu de mal à suivre en continue faute de temps et
> non pas d'intérêt- désolé...) 
  Moi c'est pile l'inverse, du coup, j'ai un peu de mal à comprendre.
  C'était quoi cette réunion au SIG ?
  Ça fait des semaines qu'on n'entend plus parler d'agora et d'un coup,
c'est la grande unification ! un résumé des épisodes précédents
s'impose je crois.

> camp de jeunes développeurs en provence (l'idée est séduisante et
> présente une défi - voir le mail de l'"avocat du diable" (Jacque s
> Pyrat sur agora-generale)
  Même remarque pour Thomas Egly : s'il y a eu des mails sur les
listes agora, ça serait sympa de prévenir, histoire qu'on puisse
suivre le fil des 2 discussions, sinon, on va passer son temps à
poser des questions dont la réponse est sur la liste du voisin.

  L'idéal serait peut être de monter une mailing list à part, spécifique
à ce projet (si elle n'existe pas déjà).
  S'il le faut, je peux en monter une en quelques minutes.

À+, Pif.

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip