Re: [SPIP Zone] Fusionner les flux de plugins externals et zone

En effet, avec tout le contexte tu ne n'extrapole pas les mots de Rasta (et
je m'excuse de n'avoir pas relu tout le fil avant de répondre.) Ceci dit,
je crois bien (à la relecture) que c'est bien l'aspect communauté SPIP qui
se porterait garant versus maintenus par une personne ou un groupe isolé
(confiance ou pas, ce point étant un des nombreux aspects que peut soulever
la question de rouler solo)

Pour en revenir à la question, je fais justement le parallèle parce-que je
trouve la gestion de SPIP avec SVP tout aussi avancé que la gestion de
paquets sous Linux (les dernières fois que j'ai regardé les autres CMS/SGC
ils faisaient pas aussi bien) d'une part et qu'ils ont cette problématique
d'autre part.
Il se trouve que techniquement on a déjà tout ce qu'il faut et que le débat
est vraiment idéologique (les dépôts étant logiques et non physiques, rien
n'empêche certains paquets hors zone de ne pas être déclaré en dépôt
externe mais plutôt le contraire) Et là dessus, je pense qu'il n'y a rien à
changer (ce qui n'engage que moi bien entendu) Ceci ne remet pas du tout en
cause le principe de plugins (je ne militais pas pour avoir des couteux
suisses mais juste pour ne pas mélanger ce qui est sous le regard de la
zone avec ce qui passe sous son radar.)

Bonne année à tous au fait (j'avais envoyé mon précédent message avant de
pouvoir rajouter ne serait-ce que les salutations) Et désolé de répondre un
peu n'importe comment (client gmail sur le phone pas terrible)




Le mer. 1 janv. 2020 21:49, Bruno Bergot <[email protected]> a écrit :

> Hop,
>
> Le 01/01/2020 à 21:05, Gildas Cotomale a écrit :
> >>
> >> Quid des plugins de tetue qui sont maintenant sur github ? On ne peut
> plus
> >> leur faire confiance ? Il ne faut plus les référencer en nécessite ? Et
> il
> >> n'y a pas que les plugins de tetue, on prive aussi les users de plugins
> >> sympas comme mastodon, markdown & tri_par_rubrique cf :
> >>
> >> https://plugins.spip.net/spip.php?page=plugins&id_depot=18
> >
> >
> > Il ne faut pas faire dire ce qui n'est pas dit... Ce n'est pas maintenu
> et
> > garanti par la communauté. Point. Cela ne remet pas en question la
> qualité
> > de des plugins et ne dit rien de la confiance ou pas en leurs auteures.
> >
>
> J'avais volontairement éludé une partie de citation, mais puisqu'elle
> semble nécessaire :
>
> Le 08/11/2019 à 10:57, RastaPopoulos a écrit :
> >
> > Je suis assez d'accord… SAUF QUE au départ externals, c'était pour les
> > plugins qui ne font PAS PARTIS de la zone démocratique à plusieurs, et
> > qui donc sont maintenus par une unique personne à part. Et donc qui
> > peuvent possiblement être considérés comme moins de confiance PAR DÉFAUT
> ...
>
> > Utiliser le moins possible des dépendances externes.
>
> Non, c'est clairement l'inverse de ce qu'on souhaite depuis des années :
> on fait tout pour avoir un plugin unique par fonctionnalité, et non des
> plugins fourre-tout, ce qui mène forcément vers l'interdépendance d'un
> plugin envers les autres.
>
> > Quand on se sent obligé de le faire, clairement mentionner dans la doc
> > qu'il faut ajouter un dépôt et lequel et comment.
> >
>
> Le point est bien là, mais si on peut éviter un "RTFM" (qu'on n'utilise
> jamais chez SPIP) et privilégier une solution simple et directe pour
> l'utilisateur, je pense que c'est "mieux".
>
> > Quand j'ai besoin d'un paquet qui n'est pas dans les dépôts officiels
> d'une
> > distribution Linux, j'ajoute le dit dépôt. Il m'est déjà arrivé d'avoir
> des
> > dépendances de paquets dans les dépôts officiels qui n'y soient pas
> > (normalement tout est fait pour que cela ne se produise pas, mais
> quelques
> > rares fois ça arrive avec un backport) et on fait la manip nécessaire.
> >
>
> Notre gestion des dépendances n'est pas encore assez aboutie pour la
> comparer à celle des paquets d'une distrib linux...
>
> PS : merci de ne plus écrire à spip-zone, cette liste est fermée,
> préfère spip-dev.
>
> ++
> b_b
>