Salut Cédric,

merci pour ces retours détaillés...

                jean marie

Le 03/10/2019 à 15:19, Cerdic a écrit :
Le 3 oct. 2019 à 13:22 +0200, Jean Marie Grall <jeanmarie.lis...@cousumain.info>, a écrit :

quel est
le meilleur emplacement pour cette forge afin d'inscrire au mieux la
communauté SPIP dans l'écosystème PHP ?

Si être dans l’écosystème veut dire s’intégrer dedans pour utiliser les composants/libs existantes et ne pas ré-écrire dans notre coin des choses qui existent déjà, je dirai peu importe.

Si être dans l’écosystème veut dire attirer des développeurs PHP dans l’univers SPIP, je dirai peu importe aussi : ça n’arrivera que très marginalement (voire pas du tout), car SPIP est totalement en dehors des standard du monde PHP parce que pas objet, documenté en français… et fait rigoler à 40km à la ronde quand tu dis juste le mot « SPIP » dans une convention PHP

Et c’est pas comme si on avait pas essayé, à commencer par Textwheel qu’on a développé initialement sur Github, en objet, avec l’idée de partager dès le début, sans succès…

J’ai essayé sur des libs qui s’y prêtaient :

https://github.com/nursit/AdaptiveImages
https://github.com/Cerdic/jQl

et j’essaye encore
https://github.com/Cerdic/geometrize-php/

Donc on peut déjà le faire à notre guise, et avoir SPIP sur notre forge n’est pas du tout un obstacle - pouvoir migrer un projet de/vers notre forge vers/de github  ou toute autre forge collective ne rend que les choses plus fluides, puisqu’on peut bouger facilement et on a pas besoin de réfléchir 107ans avant de commencer pour savoir où.

Est-ce qu'avoir sa propre forge
permettra d'avoir facilement des passerelles et donc d'embarquer des
développeurs extérieurs ?
Oui les passerelles c’est facile, on peut mirorer depuis ou vers github à volonté. Cf l’exemple de bigup qui est sur github mais mirorré sur git.spip.net, mais on peut faire le contraire. Pour le fait d’embarquer des développeurs extérieurs, je dirai que c’est neutre. Le point important est d’être en git

Où est la communauté PHP ?

Aujourd’hui sur github, qui de fait devient centralisateur d’une majeure partie du développement Open Source. Jusqu’à ce que Microsoft (ou le prochain propriétaire, qui sait ?) adopte une politique moins favorable, plus discriminatoire, et/ou ferme les comptes/projets qui ne lui reviennent pas ou qui font de la politique ou qui ne respectent pas les nouvelles conditions générales...
Ça changera : il y a eu sourceforge avant, il y aura un après.


Comment faire pour
ne pas disperser nos énergies dans de la maintenance de système d'info
(serveurs, logiciels) ? Tout cela est-il hors sujet  ?

C’est la vraie question : est-ce que le prix de l’indépendance est trop cher à payer en énergie ?
Est-ce qu’on est capable de maintenir notre forge ?
Ça fait bientôt 20 ans que SPIP fonctionne de cette façon, faut croire que c’est possible…

Et encore plus en git qu’en svn, car git étant par essence décentralisé, chaque checkout est un backup, ce qui veut dire que si tout d’un coup on perdait le serveur, le datacenter, la forge, ceux qui s’en occupe ou je ne sais quel scénario catastrophe, tout le monde peut remonter les repos où il veut et continuer le dev sans perdre d’historique. Ce qu’aujourd’hui on ne sait pas faire en SVN…

Cédric

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

Répondre à