Nettoyée, déboguée, documentée, et surtout stable, cette version note un grand pas en avant dans la vie de ce logiciel de gestion de contenu utilisé au sein de l'administration française.
Maintenu par le SIG (Service d'Information du Gouvernement), Agora 1.4 marque un tournant dans la vie du logiciel.
À l'heure où se posent les questions de l'avenir du projet et où les opinions balancent (entre une refonte du code ou un rapprochement visant la fusion avec SPIP 1.9), le SIG livre aujourd'hui une version stable qui assurera les mois à venir de ce CMS. Agora dans sa version 1.4 est la dernière distribution stable du logiciel.
La version 1.4 d'Agora viens d'être publiée et peut être téléchargée sur http://www.agora.gouv.fr/rubrique1.html.
Elle est accompagnée des paquets PEAR nécessaires à son fonctionnement. Cette version stable est l'aboutissement d'une phase complète de corrections, de nettoyage et de mise aux normes du code avec le guide de style, notamment la suppression du code SPIP obsolète en commentaires dans les fichiers.
Changements majeurs :
- La licence (GNU GPL) apparaît dorénavant clairement dans chaque fichier du projet.
- Les extensions .php3 sont abandonnées au profit de l'extension .php.
- L'encodage des fichiers est uniformisé en UTF-8, que ce soit au niveau des squelettes que des fichiers php eux-mêmes.
Intégration des fonctionnalités reversées par le ministère des Affaires étrangères et l'ANPE :
- Squelette article_X.html -> Attribue ce squelette particulier à l'article X
- Nouvel identifiant visuel signalant les articles de redirection dans l'espace privé
- Système d'alertes en cas de liens brisés vers des articles, rubriques ou documents du site ainsi que dans les cas de redirections
- Système d'extranet sur le front-office, qui permet de restreindre l'accès à des rubriques à des visiteurs identifiés
- Possibilité d'associer des contacts de type courriel à des rubriques
- Faire apparaître un article dans plusieurs rubriques (fonctionnalité de mapping)
- Prise en compte des éléments caption et summary des tableaux
N'hésitez pas à publier vos bogues et à faire part de vos retours via le système de suivi.
Aller plus loin
- www.agora.gouv.fr (10 clics)
- Guide de style en PDF (3 clics)
- Système de suivi des bogues (2 clics)
# Pourquoi un fork ?
Posté par libresurf (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Pourquoi un fork ?
Posté par Cali_Mero . Évalué à 4.
[^] # Re: Pourquoi un fork ?
Posté par Jul (site web personnel) . Évalué à 1.
Quand agora est sorti les objectifs majeurs dont je me souviens était :
- html validator compliant ;
- worklow BS compliant ;
- gestion de droit et perf.
Sur libroscope on a servi de page d'exemple pour montrer que spip pouvait passer les validator buzz bien avant qu'agora sorte, donc c'était un faux argument bien avant le fork.
Je me souviens aussi d'un benchmark qui disait sur neokraft que sur les perfs il faisait moins bien que spip.
Enfin sur le workflow, spip a pour philosophie de permettre aux gens de pouvoir s'exprimer, pour ceux qui ont l'expérience de le mise en place de workflow on constate que cela fait passer un cycle pour la publication de 3 états (inscription (1 time), rédaction,validation + publication) à au moins 5 (inscriptions, validations des droits, rédactions, validations/informations, publications). Cette philosophie orientée utilisateur est le coeur de spip ! C'est ce qui fait son succès, c'est ce qui conduit le choix dans l'acceptation de patch. Il est donc un peu étonnant d'avoir fait un fork à l'opposé de la philosophie du projet forké.
http://article.gmane.org/gmane.comp.web.spip.devel/13416/mat(...)
On pourra quoiqu'il advienne s'étonner que l'équipe SPIP ait été approchée APRÈS que le fork ait été fait. D'emblée, l'équipe de développement du fork, montrait son refus de faire du logiciel libre avec l'équipe principale. Mauvais et partial comme je suis, je pense que c'était un des enjeux majeurs. Encore plus langue de vipère je ferais remarquer que spip est plutôt proche du mouvement web indépendant (pas très respectueux des institutions politiques notamment) et que ce sont des instution
nels avec une coloration politique institutionnelle qui sont les demandeurs. Oui je soupçonne clairement un enjeu politique dans ce fork :)
Pour une SSLL/SSII l'intérêt se trouve dans le fait d'avoir une rente de situation sur le code, pour un DSI éviter de passer par des codeurs architectes permet d'éviter la contestation de choix politiques. L'ennemi d'un code bien conçu est la compléxité ainsi donc l'ajout de featurettes. On peut imaginer que spip agora aurait pu se heurter à des codeurs plus intéressés par maintenir un code simple et compact, plutôt que des développer des buzz/BS features.
Au final, une partie des squelettes et des fonctionnalités agora ne sont plus compatibles spip, donc si marque il y avait on pourrait parler à l'heure actuelle, si SPIP était fait par une multinationale de contrefaçon (portant non sur le code, mais la propriété immatérielle qu'est la marque) et de parasitage de marque. Car agora se prévaut de l'appellation spip, mais n'est plus compatible avec ce dernier.
Imaginer ce qui se passerait si Oowriter devenait Ooword/Excel/powerpoint ?
Dans le libre, on protège/libère le code, mais un jour il faudrat aussi penser à protéger/libérer les marques tout en garantissant les utilisateurs du parasitage (exemple en imposant une suite de test permettant de valider qu'à un nom de produit équivalent on ait des fonctionnalités équivalentes.).
PS entre nous je ne déteste ni n'aime spip agora.
[^] # Re: Pourquoi un fork ?
Posté par Uld (site web personnel) . Évalué à 2.
Ces tests sont anciens, (Juin 2004) pour preuve, le lien vers ce fameux bench ne répond même plus http://neokraft.net/blog/2004/06/17/515-comparaison-spip-spi(...)
- et je n'aborderai pas ici l'objectivité de ces bench...
Agora à eu le temps d'évoluer depuis, et ses lourdeurs origienelles ont largement été corrigées.
Vous pourrez trouver quelques chiffres plus récents sur le site de doc Agora (en phase de finalisation) http://agoragouv.tektonika2.com/article.php3?id_article=203
Cet argument serait recevable si Agora se targuait de vouloir être toujours compatible avec Spip, seulement ce n'est pas le cas. Agora est un projet qui a pris maintenant de la bouteille et s'est séparé de son parent. Etant basé sur un version 1.7 de Spip et ayant ensuite évolué de son propre côté, il est normal que les squelette "Spip1.9-compliant" ne passent pas sur Agora. Le logiciel n'a pas été conçu pour assurer une compatibilité avec Spip coûte que coûte...
Pourquoi parler de parasitage? Encore une fois, Agora est un logiciel qui a pris ses distances. Certes il a évolué plus ou moins proche de son parent, mais il en a aujourd'hui laisser tomber le Préfixe, et parler de Spip-Agora en pensant au parasitage n'est pas fondé puisque le projet ne comporte plus ce nom de "Spip"...
Bref, Agora a avant tout été développé pour répondre à des besoins de l'administration et les fonctionnalités additionnelle qu'il implémente sont largement reversées sur le cvs. On pourra discuter de la fidélité à vouloir suivre les évolutions de Spip de près ou de loin mais Agora reste avant tout un logiciel libre à l'usage de l'administration et dont le développement est assuré par celle ci, au bénéfice de tous. (non Agora n'est pas utilisé QUE par l'administration http://www.agora.gouv.fr/article.php3?id_article=71 )
Aujourd'hui le logiciel évolue, et les mentalités aussi. Agora 1.4 est une version majeure. La question est de savoir quelle sera la prochaine version, et s'il y en aura une, car le SIG et la DGME réfléchissent à rapprocher Agora du projet originel en reversant ses fonctionnalités sous forme de plug-in Spip (puisque celui ci les gère depuis la v1.9). Cette évolution ravirait, sans aucun doute, les défenseur pro-Spip ainsi que toute la communauté.
[^] # Re: Pourquoi un fork ?
Posté par Cali_Mero . Évalué à 3.
Ce n'est pas étonnant du tout, bien au contraire. Les qualités de spip ont permis à la base spip d'être retenue, et ses manques par rapport aux besoins exprimés par le SIG ont été développés par-dessus par la SSII. Et tu viens de justifier le fork en mettant en évidence la tendance du projet et les profondes différences philosophiques avec Agora.
[^] # Re: Pourquoi un fork ?
Posté par Jul (site web personnel) . Évalué à 3.
J'ai rien contre les forks en tant que tel, je considère juste que c'est à ne pas utiliser à tout va. En plus c'est plutôt considéré comme hostile. La façon dont le fork a été mené dont la communication a été faite, ne me semble pas respectueuse des développeurs qui ont apporté le coeur d'agora. Rien dans le libre n'oblige à être correct (en tout cas pas les licences). Rien dans le libre n'oblige à respecter les gens qui n'ont pas une once de savoir vivre. Chacun ses valeurs.
Quand je vois le nombre de CMS, de groupware, d'annuaires redéveloppés par les Collectivités Territoriales et administrations, je regarde juste les ressources qui sont gâchées, et je me demande vraiment si le but est de faire du libre un tant soit peu collaboratif avec pour objectif de ne pas réinventer la roue, ou juste de transformer l'administration en nouvelle éditeur de logiciel. Je suis très circonspect en tant que citoyen sur l'utilité de voir l'état devenir éditeur de logiciel. Je suis très circonspect en tant que personne du libre sur l'apport véritable de l'administration au logiciel libre.
[^] # Re: Pourquoi un fork ?
Posté par arnaudus . Évalué à 3.
Imagine que tu ne forkes pas. La nouvelle équipe tourne en interne très fort, et implémente les fonctionnalités dont elle a besoin. Les patches sont soumis à l'équipe de SPIP, qui reste souveraine sur le choix des patches à intégrer : celui-là oui, celui-là non. En bref, le soft qui devra répondre aux sécification va dépendre de SPIP, mais aussi d'un certain nombre de patches non officiels, dont ils ont besoin mais que les dev de SPIP ont décidé, pour de bonnes ou de mauvaises raisons, de ne pas les inclure. Plus le nombre de ces patches va être élevé, et plus les causes de bugs, incompatibilités etc. vont se multiplier. Dans le même temps, SPIP ne chôme pas, et modifie aussi le soft de leur côté, au risque de rendre les patches bricolage de l'équipe d'Agora buggués du jour au lendemain (cvs update et pouf! Tout pêté). Au final, Agora doit utiliser une vielle version du CVS pour bosser en interne, puisque se synchroniser avec SPIP risque de plus en plus de foutre la merde. Il y a de moins en moins de contributions `s SPIP, puis elles s'arrêtent complètement. Voila, c'est un fork en douceur, qui a occasionné des centaines de bugs foireux, du boulot dupliqué de chaque côté, et beaucoup de frustration. C'est donc beaucoup plus sain de tout commencer à 0 : bonjour, on a des besoins, on ne veut pas vous forcer à intégrer nos patches, alors on forke et vous pouvez venir voir de temps en temps si ça vous intéresse.
[^] # Re: Pourquoi un fork ?
Posté par Sébastien Agogué . Évalué à 3.
Etant sur linuxfr, je suis surpris par l'absence de correction ! ^^ (voire de troll ensuite !)
Sur ce, bonne soirée ! Et à bientôt pour une autre remarque constructive ! ^_^ (mademoinselles, moinsieurs, donnez-vous en à coeur joie !)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.