Un projet collectif à vu le jour cette année : réaliser une branche
spécifique à SPIP qui permette d'assurer les services nécessaires pour
un IMC (Open Publishing).
La page d'accueil du projet se trouve sur TuxFamily : http://spip-indy.tuxfamily.org
Généralement, forker un projet entraine un doublement du travail, puisque
chaque équipe va finir par réimplémenter séparément une foultitudes de
choses qui n'aurait du avoir à être faites qu'une seule fois.
Une telle décision ne peut généralement se faire qu'après avoir constaté
un désacord manifeste entre les développeurs de base du logciels et
certains développements que d'autres voudraient y ajouter.
Jusqu'à présent, SPIP, en dépis d'une gestion parfois un peu rigide, avait
su éviter le fork, qui a couté cher à pas mal d'autres projets...
Etait-il nécéssaire d'en arriver là dans le cas présent ?
Un projet collectif à vu le jour cette année : réaliser une branche
spécifique à SPIP qui permette d'assurer les services nécessaires pour
un IMC (Open Publishing).
La page d'accueil du projet se trouve sur TuxFamily : http://spip-indy.tuxfamily.org
Généralement, forker un projet entraine un doublement du travail, puisque
chaque équipe va finir par réimplémenter séparément une foultitudes de
choses qui n'aurait du avoir à être faites qu'une seule fois.
Une telle décision ne peut généralement se faire qu'après avoir constaté
un désacord manifeste entre les développeurs de base du logciels et
certains développements que d'autres voudraient y ajouter.
Jusqu'à présent, SPIP, en dépis d'une gestion parfois un peu rigide, avait
su éviter le fork, qui a couté cher à pas mal d'autres projets...
Etait-il nécéssaire d'en arriver là dans le cas présent ?
bonjour,
Ce n'est en aucun cas un fork (gasp). La branche indymedia (spip-indy) est un squelette propre aux IMC (http://indymedia.org), quelques fichiers pour gérer l'open-publishing et une entrée supplémentaire dans la base de donnée.
La philosophie est "no touch la branche principale = the spip :)" Mais plutot de créer un ensemble de fichiers qui *s'additionnent* à ceux de spip. Pour installer un spip-indy, il faut installer un spip uzine... le fichier install est modifié pour install la base_op, c'est tout.
Notre idée, n'est pas un fork, mais plutot un module supplémentaire. Vérifiez : décompressez un spip dans un dossier, ajouter le spip-indy. 1 ou 2 fichiers sont écrasés (on tend à vouloir faire 0, avec une install séparée). Résultat : un spip-indy.
Le but est de répondre aux contraintes d'un site de publication ouverte (open publishing = contributions) en plus d'un spip uzine. Mais certainement pas de fork ! Loin de nous cette idée, bien au contraire. Le choix de spip pour les imc en cours s'appuie sur la communauté très active de spip. Cela permet de s'appuyer sur elle pour le site... seul le module Op etant à gérer.
Il est impérativement précisé sur le projet spip-indy, que ces développements ne doivent *que* s'ajouter à un SPIP et en aucun cas modifier le source.
(... je suis au boulot... donc peu de temps mais je répondrai volontier à vos questions par mail. Mais pas de panique spip-indy n'est pas un fork... Pas de double travail !!!
Je crois que notre petit camarade à raison, il ne faut pas confondre fork et
customisation (désolé pour le barbarisme) : un des intérêt du logiciel libre
c'est justement de pouvoir l'adapter à ses besoins propres (lire la GPL).
Ce qui est intéressant dans la façon dont indy mène l'affaire c'est qu'ils
maintiennent la compatibilité avec le script d'origine en y intégrant les
réponses à leurs besoins spécifiques.
Ce n'est en aucun cas un fork (gasp). La branche indymedia (spip-indy)
est un squelette propre aux IMC (http://indymedia.org), quelques
fichiers pour gérer l'open-publishing et une entrée supplémentaire dans
la base de donnée.
En disant "on a une branche dans un CVS", tu nous as fait penser à un fork.
Mais la question tient toujours : les modifs que vous avez apportées
seraient-elles intégrables directement dans SPIP, via une configuration
avancée ? Qu'est-ce qu'elles apporteraient ?
Pour qu'on puisse évaluer ça, il faudrait que tu décrives précisément
quelles sont ces modifs, et qu'on en discute ensemble. Sinon, vous
maintiendrez vos modifs en parallèle, et elles clasheront un jour ou l'autre
avec les nôtres...
C'est effectivement une option que spip ne propose pas. Moi je suis contraint de
faire une entrée visiteur/visiteur pour ça, et c'est sûrement pas la meilleure
solution (un visiteur efface un autre). J'en avais déjà parlé mais bon... C'est
pas parce que xoops et nuke le font qu'il ne faut pas le faire hein.
Un site hyper interactif comme spip qui ne propose pas ça sans passer par une
rébarbative et dissuasive inskription à l'administraazionne, ça fait paradoxe
pour moi. C'est un peu comme ecrire ADMIN au lieu de REDAC pour accueillir les
écrivains !?
Et si je dois attendre que spip de base se décide, ben bienvenue à IndySpip :o)