Re: [SPIPremix] Une distribution SPIP alternative

Le 1 juillet 2018 à 21:44, Maïeul <[email protected]> a écrit :

>
>
>>
>> Sur les usages
>> --------------
>>
>> Composer et Git modifieraient grandement les usages en basculant dessus.
>> Est-ce que notre petite communauté d’utilisateurs de la zone est prête à
>> basculer ? J’ai le vague sentiment que oui (composer et git se sont
>> largement démocratisés).
>>
>> Ça nécessite tout de même de revoir grandement le Spip Loader pour
>> l’installation facile sans terminal (mais dans ce cas là il faut que SVP
>> puisse continuer à télécharger de lui même les plugins…).
>>
>> Ou doit-on dire, maintenant, pour installer SPIP, il faut un accès shell
>> ? installer composer, et lancer le create… les require… ?
>> Est-ce que ça ne va pas un peu à l’encontre d’une simplicité/facilité
>> d’usage que l’on souhaitait ?
>>
>>
>> A mon sens, il faut que SPIP puisse encore être installé classiquement en
> telechargeant le loader/un zip et en envoyant par ftp.
>
> Sinon, on risque de perdre de tas d'utilisateur/trices qui n'ont accès
> qu'ầ du ftp...
>
> J'imagine que SPIP ne sera pas le seul CMS a proposer les deux modes
> d'installations non?
>
>
On pense, on croit, on imagine, mais en vérité, je te le dis, on ne sait
rien, sinon une chose : on perd des utilisateurs tous les jours et ceci
depuis le début 2014 alors qu'on n'est en rien responsable des transferts
ftp qu'ils peuvent faire mais qu'ils ne font pas. Ce n'est pas un risque,
c'est un fait.

Un autre fait est qu'on ne sait pas quelle proportion d'utilisateurs
déploient du SPIP avec "spip_loader" ou par "téléchargement manuel de
zip+ftp" ou "svn local+ftp" ou "ssh+svn" ou "apt sur debian" ou
"ssh+spip-cli" ou "yunohost" ... ou tout autre combinaison, en fonction des
besoins, de ce que permet l'espace privé, de l'hébergeur et de ce qui est
requis pour des plugins ou des "libs" à "installer".

D'après ce que j'observe, c'est probablement le contraire qui se produit :
on perd des utilisateurs depuis 4 ans et demi, parce que nous n'avons pas
fait évoluer nos méthodes de déploiement. Mais, je l'accorde par avance,
c'est peut-être un biais de confirmation de ma part. (attention humour : )
Mais, du coup, je rétorque que peut-être, mais moi, je cherche à corréler
des faits, je ne me contente pas d'imaginer ou de croire. (fin humour)

Bref, tout ça pour dire que si le seul argument pour demander à la
communauté de maintenir spip_loader, c'est qu'on pourrait perdre des
utilisateurs, je le considère comme irrecevable tant qu'on ne m'aura pas
apporter la preuve que c'est ce dont les utilisateurs encore les plus
actifs sont le plus dépendants.

J'ajoute aussi que je ne connais pas beaucoup d'hébergeurs qui fournissent
un accès à leurs machines avec (s)ftp comme seule méthode de déploiement.

Toutefois, rien n'empêche, si on n'a pas d'accès ssh à un serveur hôte, de
déployer à peu près n'importe quelle application basée sur autre chose que
SPIP avec (s)ftp. Il existe même, si on cherche bien, de quoi automatiser
ces déploiements et gérer les fichiers à supprimer. Si d'autres peuvent le
faire, SPIP peut continuer à le faire.

Enfin, il est difficile, voire impossible, de prouver l'inexistence de
quelque chose, mais je peux au moins dire que je ne vois plus, depuis
quelques années, de méthode "web" d'installation "à la spip_loader"
d'autres applications web, sur le plan officiel en tout cas.

D'ici-là, il y a plein d'autres points soulevés par Matthieu qui méritent
aussi des réponses.
Parmi les choses oubliées, il y a la question des traductions/fichiers de
langue ;-)

Amicalement,
-- 
James