Re: [SPIP Zone] Mise à jour git.spip.net

2019-09-16 Par sujet Maïeul Rouquette
Le lundi 16 septembre 2019 à 10:53 +0200, cam.la...@azerttyu.net a
écrit :
> Bonjour
> 
> > je reprend suite à ce fil de discussion, aux remarques d'Eric et de
> > JLuc.
> > 
> > Si j'ai bien compris git.spip.net serait désormais opérationnel,
> > structurée et on pourrait brancher dessus smart-paquer?
> 
> Comme tu peux le lire il me semble que ce soit prématuré.
> Le service est fonctionnel pour la partie core de SPIP , expérimental
> pour la partie plugin.
> Pour le moment git.spip.net ne couvre pas l'intégralité de la zone et
> cela ne semble même pas son objectif à terme, vu les précédents
> échanges.
> 
> > SI oui est-ce que ce serait possible d'avoir un article en résumant
> > l'usage.
> 
> C'est à dire ?

vu que c'est prématuré, alors non.

Mais en gros ma demande serait un article pour
1) migrer de zone vers git.spip.net
2) permettre le lien avec smart-paquet



spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-09-16 Par sujet cam.la...@azerttyu.net
Bonjour

> je reprend suite à ce fil de discussion, aux remarques d'Eric et de JLuc.
>
> Si j'ai bien compris git.spip.net serait désormais opérationnel,
> structurée et on pourrait brancher dessus smart-paquer?

Comme tu peux le lire il me semble que ce soit prématuré.
Le service est fonctionnel pour la partie core de SPIP , expérimental
pour la partie plugin.
Pour le moment git.spip.net ne couvre pas l'intégralité de la zone et
cela ne semble même pas son objectif à terme, vu les précédents
échanges.

> SI oui est-ce que ce serait possible d'avoir un article en résumant l'usage.

C'est à dire ?

> Je pourrais alors migrer petit à petit les plugins.

C'est à dire ?

Remarque : le fil de discussion est dédié à la mise à jour de
git.spip.net, il serait préférable d'ouvrir de nouveaux fil de
discussion pour aider à la compréhension des échanges.

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-09-16 Par sujet Maïeul

Le 20/08/2019 à 09:06, cam.la...@azerttyu.net a écrit :

Bonjour

Je reprends le fil d'origine de cette discussion.

La mise à jour a été faite 1.9.1 est en production. Il s'agit
principalement de correctifs divers.
https://blog.gitea.io/2019/08/gitea-1.9.1-is-released/

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


je reprend suite à ce fil de discussion, aux remarques d'Eric et de JLuc.

Si j'ai bien compris git.spip.net serait désormais opérationnel, 
structurée et on pourrait brancher dessus smart-paquer?


SI oui est-ce que ce serait possible d'avoir un article en résumant l'usage.

Je pourrais alors migrer petit à petit les plugins.


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-09-10 Par sujet cam.la...@azerttyu.net
Bonjour

Le serveur git.spip.net a été mis à jour à la version 1.9.3
https://blog.gitea.io/2019/09/gitea-1.9.3-is-released/

Dans le même temps il y a eu des évolutions de fonctionnement, ce
n'est pas du technique plutôt de l'organisationnel et c'est toujours
en cours.
* Les organisations ont été restructurées, avec des regroupements et
des renommages. (C'est pour suivre la discussion en cours "[spip-dev]
Nombre et noms des organisations Git") N'hésitez pas à continuer à en
discuter sur ce fil dédié.
* Les plugins-dist ont été tous regroupés dans l'organisation SPIP
(pour le moment SPIP c'est aussi bien son core que ses plugins-dist)
* L'organisation "plugin" regroupe n'importe quel type de plugin. Il
suffit d'avoir un plugin.xml/paquet.xml
* L'organisation "contrib" regroupe ce qui ne peut être dans "plugin"

Comme dit au début c'est une évolution en cours et une discussion
dédiée est déjà ouverte.

* Les projets présents dans la forge sont maintenant tous par défaut
sans wiki, sans ticket. Ceci est dû au fait que tous les membres
inscrits à la zone sont notifiés. Ce n'est pas le comportement
attendu/voulu.
Pour rappel actuellement :
* Pour tout ce qui concerne "SPIP" (core et plugins-dist) les tickets
sont uniquement sur core.spip.net
* Pour tout les autres cas (plugin/contrib/...) il n'y a pas pour le
moment de comportement standard. La solution recommandée est
contrib.spip.net, des expérimentations autres sont en cours.


Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-27 Par sujet cam.la...@azerttyu.net
Bonjour

Le serveur git.spip.net a été mis à jour à la verison 1.9.2
https://blog.gitea.io/2019/08/gitea-1.9.2-is-released/

Il s'agit principalement de correctifs

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-20 Par sujet cam.la...@azerttyu.net
Bonjour

Je reprends le fil d'origine de cette discussion.

La mise à jour a été faite 1.9.1 est en production. Il s'agit
principalement de correctifs divers.
https://blog.gitea.io/2019/08/gitea-1.9.1-is-released/

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-10 Par sujet Cerdic
Oui alors, va quand même falloir arrêter avec cet argument de « si on est pas 
sur github on sera pas sur packagist et du coup les gens pourront pas installer 
leur package depuis composer sans faire des manips compliquées »

1/ on est d’accord sur le point 1 qu’il suffit d’avoir spip/spip sur packagist 
pour que tout le « composer create spip/spip » fonctionne et qu’ensuite sur un 
projet SPIP tu peux installer tous les packages que tu veux depuis 
packages.spip.net, sans aucune manip supplémentaire

2/ le cas hypothétique de « je veux que SPIP fonctionne dans vendor comme un 
composant sur un autre projet » on va l’oublier si tu veux bien, il y a des 
bonnes chances pour que composer soit has been mort et remplacé par autre chose 
avant que ça n’arrive - et si t’as pas d’accord, va directement au point 3

3/ le cas de la lib super générique qu’on veut pouvoir redistribuer autre part 
(comme TextWheel, souvenez vous, que d’émotion…)
Ma réponse n°1 c’est : quelqu’un qui est venu chercher une lib dans l’univers 
SPIP et veut l’utiliser n’aura pas trop de difficulté à ajouter la directive « 
repositories » dans son composer.json
Ma réponse n°2 c’est : hé, si on veut être visible c’est super simple : on 
ajoute dans le smart-paquet/ ou quel que soit l’outil qui le remplace, à chaque 
push ou mise à jour un
curl -XPOST -H'content-type:application/json' 
'https://packagist.org/api/update-package?username=Spip=API_TOKEN' 
-d'{"repository":{"url":"PACKAGIST_PACKAGE_URL"}}'
et pouf on a un package sur packagist à jour automatiquement.
Passer à Github pour éviter un curl, c’est quand même un peu le comble…

Et je rappelle que dans tous les cas, github ou pas, il faut aller soumettre 
chaque projet sur Packagist manuellement la première fois.
On ne trouvera donc que les packages qui auront été publié là-bas, dans une 
démarche volontaire et consciente (pas de magie)


Ensuite l’argument de « on n’est pas assez nombreux, maintenir nos outils ça 
nous tue », est à mon sens totalement hypocrite et mensonger.

Ce qui nous tue c’est de systématiquement tirer dans les pattes et freiner ceux 
qui font quelque chose, au pretexte que « si on faisait autrement ça serait 
mieux », le « on » n’étant en l’occurence jamais celui qui le prononce, qui se 
contente de dire qu’il aimerait autre chose.

Alors oui « on » pourrait faire autrement, mais « on » a déjà une forge git qui 
fonctionne, « on » peut commiter en git sur SPIP
(est-ce que je devrai suggérer que ceux qui n’ont même pas encore essayé de 
checkout SPIP en git et/ou de commit ou faire une PR devrait commencer par là 
pour avoir un avis éclairé à ce débat ?), « on » a un outil de conversion des 
projets de la zone vers git et cette forge

Et *je* ferai le super gros outil très compliqué qui curl packagist.org pour 
mettre à jour les packages composer si on est pas sur github, puisque c’est 
vraiment un point crucial dans tout ce débat.

Et donc j’ai du mal à voir pourquoi « on » devrait jeter tout le travail fait 
par Camille, qui est certes perfectible, à partir du moment où ça n’entrave 
rien.
Mais si « on » met la même énergie à tout faire marcher qu’à râler je n’ai pas 
de toute que tout ira bien.

--
Cédric
Le 9 août 2019 à 19:51 +0200, Matthieu Marcillaud , a écrit :
> Le 09/08/2019 à 15:11, Cerdic a écrit :
> > Pour faire avancer le schmilblick (ou pas), je note quand même ici pour
> > les records que techniquement, seul le paquet principal root spip/spip a
> > besoin d’être sur Packagist.org et donc sur github
> > Car il peut ensuite déclarer le dépot https://packages.spip.net sur
> > lequel on retrouvera tout SPIP et la zone et tuti quanti
> > https://getcomposer.org/doc/04-schema.md#repositories
> >
> > Ça veut donc dire qu’on peut très bien avoir notre git et mirorer
> > simplement spip/spip sur github, [...] (ou alors j’ai pas bon ?)
>
> (je fais que passer)
>
> Alors sur ce point précis, oui, si tu lances «composer create-project
> spip/spip), afin de copier (entre autres) son composer.json à la racine
> de ton projet. La déclaration des repositories ne fonctionnent qu’à la
> racine.
>
> C’est à dire que si un jour quelqu’un·e tenterait soit :
>
> A) composer require spip/spip (ce qui le placerait dans vendor/, ça
> fonctionnerait pas (bon actuellement SPIP ne peut pas fonctionner de la
> sorte cependant)
>
> B) si quelqu’un veut simplement une librairie, un plugin de SPIP,
> "composer require spip/bidule" ne fonctionnera pas si son composer
> racine à lui n’a pas la déclaration du repository.
>
>
> MM.
>
> 
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-10 Par sujet Eric Lupinacci
Re,


Le sam. 10 août 2019 à 00:42, Mist. GraphX 
a écrit :

> Le 09/08/2019 à 22:49, nicod_ a écrit :
> > Le 09/08/2019 à 16:41, Luis Speciale a écrit :
> >> On a toujours été des ayatollahs du non fric, non proprio et tout le
> >> collier de perles et on va changer maintenant ?
> >
> > Ton adresse est bien lspeci...@gmail.com ? Sérieusement ?
> >
> > Best résumé ever du foutage de gueule oui...
> >
> ;-) ++1
>
>
Et les amis, je n'ai pas l'impression que la communauté SPIP soit une secte
et que le grand Gourou Polatouche nous impose sa pensée unique !
Heureusement qu'on a tous nos travers et nos contradictions, ça nous rend
encore un peu humain.

Alors oui SPIP porte des valeurs qu'on partage tous je pense mais on a
jamais eu besoin d'être d'accord sur tout pour avancer. Par contre, on a
toujours cette même difficulté chronique à prendre des décisions et là ça
commence à devenir insupportable.

En fait, j'ai le sentiment qu'il y a un manque de courage à exprimer les
choses comme elle le doivent. On continue à débattre de problématiques que
tout le monde a compris ou alors à s'invectiver alors que l'on demande à
faire un choix. C'est quoi qui est si difficile :
- de prendre une décision qui emmerde Camille qui a bossé sur le sujet
(avec le groupe Composer) depuis des mois ?
- ou qu'on aurait du mal à soutenir dans l'avenir la décision qui pourrait
être prise ?

Si on est une équipe, il n'y a aucune raison de ne pas prendre une décision
et de *tous* faire en sorte que ça fonctionne par la suite.
Alors GitHub ou Gitea ?

++
Eric

PS: désolé si le mail peut paraitre moralisateur, c'est pas le propos.

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-10 Par sujet Eric Lupinacci
Hello,


Le ven. 9 août 2019 à 21:36, nicod_  a écrit :

> Le 09/08/2019 à 18:15, Eric Lupinacci a écrit :
> > Finalement après tous ces échanges, certains supplémentaires sur IRC et
> > même de honteuses discussions en privé (gnarf, gnarf) j'en arrive à me
> > dire que je préfèrerais continuer le travail Gitea actuellement mené par
> > Camille pour passer définitivement la zone et spip en Git, et ce
> > rapidement.
>
> Ne mélangeons pas tout : on parle du core de spip + ses plugins dist
> versionnés en Git, et de leur installation par Composer.
>
> La zone, c'est un autre sujet.
>

Non.
Pas pour le passage à Git.
Pour composer oui c'est la première étape.
Pour Git l'intérêt de passer une partie et pas l'autre est plus que douteux
et franchement moi je n'ai pas envie me taper deux zones ad vitam eternam.
Le fait de passer à Git partout est juste une question de fournir des
explications de façon claire à des gens qui connaissent déjà la gestion de
version et donc le code et ça on peut même le faire par anticipation.

Donc en l'occurrence, sur ce sujet je ne mélange pas tout (même si ça
m'arrive parfois aussi), je donne juste mon point de vue nicod, rien de
plus.

++
Eric

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Mist. GraphX

Le 09/08/2019 à 22:49, nicod_ a écrit :

Le 09/08/2019 à 16:41, Luis Speciale a écrit :

On a toujours été des ayatollahs du non fric, non proprio et tout le
collier de perles et on va changer maintenant ?


Ton adresse est bien lspeci...@gmail.com ? Sérieusement ?

Best résumé ever du foutage de gueule oui...


;-) ++1

l'internet bio , élevé au grain de chez Monsanto arrive !!

Bon ok je sort ^^ je retourne dans mon parc avec les écureuils …

Bises et bonne vacances à tous-toutes etc …

--
Bonne journée
Arnaud B. (Mist. GraphX)



spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet nicod_

Le 09/08/2019 à 16:41, Luis Speciale a écrit :

On a toujours été des ayatollahs du non fric, non proprio et tout le
collier de perles et on va changer maintenant ?


Ton adresse est bien lspeci...@gmail.com ? Sérieusement ?

Best résumé ever du foutage de gueule oui...

--
nicod_

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet nicod_

Le 09/08/2019 à 18:15, Eric Lupinacci a écrit :
Finalement après tous ces échanges, certains supplémentaires sur IRC et 
même de honteuses discussions en privé (gnarf, gnarf) j'en arrive à me 
dire que je préfèrerais continuer le travail Gitea actuellement mené par 
Camille pour passer définitivement la zone et spip en Git, et ce 
rapidement.


Ne mélangeons pas tout : on parle du core de spip + ses plugins dist 
versionnés en Git, et de leur installation par Composer.


La zone, c'est un autre sujet.

--
nicod_

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet nicod_

Le 09/08/2019 à 16:59, Cerdic a écrit :

Merci Luis, meilleur résumé ever!


Sans avoir lu tout ce que James a écrit sur le sujet.

Donc, il faudrait aussi maintenir notre propre installation de Satis, en 
plus de tout le reste, tout ça pour pouvoir dire "on est libres" ?


Super, une bonne stack maison, bien obscure, maintenue par quelqu'un 
(qui ?), à laquelle personne ne comprendra rien quand ça pètera.


--
nicod_

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet RastaPopoulos


> Merci Luis, meilleur résumé ever!

Bé non, le meilleur résumé, c'est aussi le point rappelé par Marcimat
juste avant, pour l'instant.

Et c'est pour ce genre de merdouille, que non ça ne suffit absolument
pas que juste "spip/spip" soit sur packagist, et que donc juste
"spip/spip" soit sur Github, avec tout le reste ailleurs.

Et pareil pour les plugins donc ou autre projet de la communauté qui
pourraient être utilisés ailleurs (y compris d'autres distributions
donc, pas perso mais bien maintenues par la communauté, geodiv ou autre).

> Finalement après tous ces échanges, certains supplémentaires sur IRC et
> même de honteuses discussions en privé (gnarf, gnarf) j'en arrive à me
> dire que je préfèrerais continuer le travail Gitea actuellement mené par
> Camille pour passer définitivement la zone et spip en Git, et ce
> rapidement. 

D'après ce que je comprends toujours de Composer, je ne vois toujours
pas de solution vraiment pour que les choses soient ailleurs et que ce
soit facile de tout installer *ou dépendre* depuis un autre projet, afin
de s'insérer un peu dans l'écosystème PHP.

Le but c'est pas juste pour nous qui connaissons tout déjà (dans ce cas
fuck composer), mais bien à la fois pour pouvoir dépendre de libs
externes facilement, et de pouvoir déployer des choses SPIP avec
composer (donc installer et dépendre avec les require).

Techniquement, pour le noyau dans un projet temps, c'est pas des trucs
nouveaux à coder, quasiment tout est là (voire vraiment tout). Mais il
faut que tout soit sur Packagist, donc sur github.com ou gitlab.com. Et
le problème se posera encore plus pour les plugins ensuite, le garder en
tête.

Là on doit déjà passer un peu de temps à débattre et définir vers quelle
infrastructure on bascule, donc autant passer direct à un truc qui a une
vue un peu plus loin que juste Git ou juste "la dist de base" en
composer. Ce n'est pas comme si c'était un chantier plus important que
de rester avec nos trucs maintenus persos, c'est justement plutôt l'inverse.

Dépendre de services tiers, ça se réfléchit évidemment au cas par cas,
suivant quelle dépendance on accepte : si on est assuré que tout 100%
peut être déplacé en peu de temps ailleurs, si un jour ça se gâte, ya
quand même immensément moins de frein. Car là on ne le fait pas parce
qu'on trouve le Grand Capital super plus cool et ergonomique (avoir son
instance Gitlab c'est très bien), mais prosaiquement parce que Packagist
ne gère que github.com. Si un jour c'est facile d'installer depuis son
instance sans demander de la config aux utilisateurs, on se barre
ailleurs et basta.

J'ai lu des trucs sur IRC qui disaient "au moins là on aura Git
rapidement, ça sera déjà ça, et Composer ça n'existe pas encore, on
verra quand ça avancera". Mais justement ! Ça va vers l'argument inverse
: ça fait longtemps que Composer ça traine, et si on choisit une
infrastructure qui va rendre encore plus embêtant sa mise en place et
son utilisation, bah ça augmentera sûrement la probabilité que ça recule
encore.

Mais si on me prouve qu'on peut avoir nos trucs persos *sans gêner
aucune utilisation facile*, et pas juste pour la dist de base (un des
multiples buts du découpage et de composer, c'est de pouvoir avoir plus
de distributions complètes, et facile à maintenir, donc à distribuer
aussi), alors super, moi aussi évidemment je trouve mieux quand on a des
outils libres (et que plus d'une personne sait).

-- 
RastaPopoulos


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Matthieu Marcillaud

Le 09/08/2019 à 15:11, Cerdic a écrit :
Pour faire avancer le schmilblick (ou pas), je note quand même ici pour 
les records que techniquement, seul le paquet principal root spip/spip a 
besoin d’être sur Packagist.org et donc sur github
Car il peut ensuite déclarer le dépot https://packages.spip.net sur 
lequel on retrouvera tout SPIP et la zone et tuti quanti

https://getcomposer.org/doc/04-schema.md#repositories

Ça veut donc dire qu’on peut très bien avoir notre git et mirorer 
simplement spip/spip sur github, [...] (ou alors j’ai pas bon ?)


(je fais que passer)

Alors sur ce point précis, oui, si tu lances «composer create-project 
spip/spip), afin de copier (entre autres) son composer.json à la racine 
de ton projet. La déclaration des repositories ne fonctionnent qu’à la 
racine.


C’est à dire que si un jour quelqu’un·e tenterait soit :

A) composer require spip/spip (ce qui le placerait dans vendor/, ça 
fonctionnerait pas (bon actuellement SPIP ne peut pas fonctionner de la 
sorte cependant)


B) si quelqu’un veut simplement une librairie, un plugin de SPIP, 
"composer require spip/bidule" ne fonctionnera pas si son composer 
racine à lui n’a pas la déclaration du repository.



MM.


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Bruno Bergot

Hop,

Le 09/08/2019 à 16:41, Luis Speciale a écrit :


Ça ne pourrait pas aider ?

https://github.com/composer/satis



Oui et c'est bien mentionné depuis le début ;)

https://spip.lerebooteux.fr/Mise-en-place-du-depot-Composer

Mais bon, il semble utile de dire les choses trois fois en ce moment, 
donc (une fois de plus) merci pour le rappel :D


++
b_b

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Eric Lupinacci
Hello,

Le ven. 9 août 2019 à 17:00, Cerdic  a écrit :

> Merci Luis, meilleur résumé ever!
>
> On a toujours été des ayatollahs du non fric, non proprio et tout le
> collier de perles et on va changer maintenant ?
>
> Puis, puisque on est à l'article de voter (?), même si personne ne m'a
> pas demandé mon avis, je serais pour continuer avec le projet de Cam.
>
> Et une fois vous aurez décidé, pourrait-on avoir un tutoriel de comment
> passer vers composer gitea ou quoi ou qu'est-ce?
>
> Je plus ou moins suivi les discussions jusqu'à que j'ai eu le tournis et
> me suis laissé dire que l'avenir sera plus clair. Là je nage un peu.
>
>
Finalement après tous ces échanges, certains supplémentaires sur IRC et
même de honteuses discussions en privé (gnarf, gnarf) j'en arrive à me dire
que je préfèrerais continuer le travail Gitea actuellement mené par Camille
pour passer définitivement la zone et spip en Git, et ce rapidement.
Alors oui il va falloir assurer, en particulier Camille mais je pense que
sinon on est pas prêt de voir quelque chose d'autre que notre vieille zone
SVN (qui fonctionne très bien au demeurant, c'est pas le problème). Si
l'utilisation nous apparait in fine non satisfaisante on pourra toujours
changer pour github ou gitlab sachant que le seul problème véritable réside
dans la migration des tickets.

Et franchement ça me semble la meilleure voie dans l'immédiat pour enfin
avancer sur Composer même si ça va nous demander de l'huile de coude.

Donc je vote Gitea !

Maintenant Camille, si on se décide enfin pour Gitea, il faudra concocter
une doc de maintenance qui permette à d'autres de t'aider.

Voilà pour moi.
A vous lire les amis.

++
Eric

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet erational

Hello

Je suis d'accord avec Luis.

Depuis le début, on possède nos outils indépendants "orthodoxes".
Si on peut continuer dans cette voie, je vote pour même si l'utilisation 
au départ un peu rugueuse.


Je n'ai pas suivi tous les détails de la discussion, mais si ony  a un 
article qui explique la démarche pour adopter la nouvelle plateforme, 
j'arrive avec enthousiasme :)


Encore merci à tous.

Bisous

Le 09/08/2019 à 16:41, Luis Speciale a écrit :

Le 08/08/2019 à 19:28, Bruno Bergot a écrit :

Hop,

Le 07/08/2019 à 16:21, RastaPopoulos a écrit :

Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
json etc), il ne sait installé QUE ce qui est pris en charge par le
dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
l'instance officielle).

Ça ne pourrait pas aider ?

https://github.com/composer/satis


D'autre part j'avoue ne pas très bien comprendre pourquoi ne pas faire
avec ce qu'a été fait. Je veux dire

https://git.spip.net/SPIP/prive

au lieu de Github

On a toujours été des ayatollahs du non fric, non proprio et tout le
collier de perles et on va changer maintenant ?

Puis, puisque on est à l'article de voter (?), même si personne ne m'a
pas demandé mon avis, je serais pour continuer avec le projet de Cam.

Et une fois vous aurez décidé, pourrait-on avoir un tutoriel de comment
passer vers composer gitea ou quoi ou qu'est-ce?

Je plus ou moins suivi les discussions jusqu'à que j'ai eu le tournis et
me suis laissé dire que l'avenir sera plus clair. Là je nage un peu.


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone



--
_
https://www.erational.org


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Cerdic
Merci Luis, meilleur résumé ever!

--
Cédric
Le 9 août 2019 à 16:42 +0200, Luis Speciale , a écrit :
> Le 08/08/2019 à 19:28, Bruno Bergot a écrit :
> > Hop,
> >
> > Le 07/08/2019 à 16:21, RastaPopoulos a écrit :
> > >
> > > Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
> > > CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
> > > json etc), il ne sait installé QUE ce qui est pris en charge par le
> > > dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
> > > DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
> > > l'instance officielle).
>
> Ça ne pourrait pas aider ?
>
> https://github.com/composer/satis
>
>
> D'autre part j'avoue ne pas très bien comprendre pourquoi ne pas faire
> avec ce qu'a été fait. Je veux dire
>
> https://git.spip.net/SPIP/prive
>
> au lieu de Github
>
> On a toujours été des ayatollahs du non fric, non proprio et tout le
> collier de perles et on va changer maintenant ?
>
> Puis, puisque on est à l'article de voter (?), même si personne ne m'a
> pas demandé mon avis, je serais pour continuer avec le projet de Cam.
>
> Et une fois vous aurez décidé, pourrait-on avoir un tutoriel de comment
> passer vers composer gitea ou quoi ou qu'est-ce?
>
> Je plus ou moins suivi les discussions jusqu'à que j'ai eu le tournis et
> me suis laissé dire que l'avenir sera plus clair. Là je nage un peu.
>
> 
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Luis Speciale
Le 08/08/2019 à 19:28, Bruno Bergot a écrit :
> Hop,
> 
> Le 07/08/2019 à 16:21, RastaPopoulos a écrit :
>>
>> Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
>> CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
>> json etc), il ne sait installé QUE ce qui est pris en charge par le
>> dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
>> DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
>> l'instance officielle).

Ça ne pourrait pas aider ?

https://github.com/composer/satis


D'autre part j'avoue ne pas très bien comprendre pourquoi ne pas faire
avec ce qu'a été fait. Je veux dire

https://git.spip.net/SPIP/prive

au lieu de Github

On a toujours été des ayatollahs du non fric, non proprio et tout le
collier de perles et on va changer maintenant ?

Puis, puisque on est à l'article de voter (?), même si personne ne m'a
pas demandé mon avis, je serais pour continuer avec le projet de Cam.

Et une fois vous aurez décidé, pourrait-on avoir un tutoriel de comment
passer vers composer gitea ou quoi ou qu'est-ce?

Je plus ou moins suivi les discussions jusqu'à que j'ai eu le tournis et
me suis laissé dire que l'avenir sera plus clair. Là je nage un peu.


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet RealET

Bonjour,

Je rebondis sur ça pour poser une question.
Il me semble que l'objectif sous-jacent à toute cette réflexion, c'est 
de rendre la participation au core (sous forme de PR) et à SPIP en 
général *plus ouverte à plus de monde* qu'actuellement.


Si c'est bien le cas, il me semble que la question n'est plus qu'entre 
GitHub ou GitLab.com, qui sont les 2 espaces de développement *"de 
fait"* de la communauté open-source.


*Github* est celui qui a de plus la *meilleure exposition médiatique* 
(fork me on Github).
Et Gitlab.com a prouvé qu'il pouvait récupérer un projet de GitHub (avec 
Issues et PR et plus encore 
https://docs.gitlab.com/ee/user/project/import/github.html).


Donc, il me semble qu'il serait plus efficace de passer à GitHub (tout 
en sachant qu'on pourrait passer à GitLab et/ou mettre en place un repo 
communautaire s'il le fallait).


Et en disant cela, ça me fend le cœur que ça puisse conduire à ne pas 
utiliser tout ce que Camille a fait, testé, mis en place.

Donc, merci à toi Camille, quelle que soit la décision finale.
Et de grosses bises !


PS : une lecture passionnante sur les dangers de GitHub : 
https://carlchenet.com/le-danger-github-revu-et-augmente/
PS² : témoignage personnel : un des avantages de GitHub, c'est de 
pouvoir soumettre un PR juste en modifiant le code source via l'éditeur 
en ligne fourni par GitHub. Pratique quand je n'ai pas voulu passer par 
un client Git en local (que je ne savais pas utiliser à l'époque).


--
RealET

Cerdic a écrit le 09/08/2019 à 15:11 :
Pour faire avancer le schmilblick (ou pas), je note quand même ici pour 
les records que techniquement, seul le paquet principal root spip/spip a 
besoin d’être sur Packagist.org et donc sur github
Car il peut ensuite déclarer le dépot https://packages.spip.net sur 
lequel on retrouvera tout SPIP et la zone et tuti quanti

https://getcomposer.org/doc/04-schema.md#repositories

Ça veut donc dire qu’on peut très bien avoir notre git et mirorer 
simplement spip/spip sur github, ce qui n’est pas la mort
Après la question est donc de ce qu’on veut faire, de ce qu’on a 
l’energie de faire, de si on préfère se faire hoster par le grand 
capital-que-quand-même-finalement-ils-sont-gentils on si on a encore un 
petit peu d’idéaux etc…


(ou alors j’ai pas bon ?)

Des bises en tout cas
(c’est le seul truc qui marche encore un peu)




spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-09 Par sujet Cerdic
Pour faire avancer le schmilblick (ou pas), je note quand même ici pour les 
records que techniquement, seul le paquet principal root spip/spip a besoin 
d’être sur Packagist.org et donc sur github
Car il peut ensuite déclarer le dépot https://packages.spip.net sur lequel on 
retrouvera tout SPIP et la zone et tuti quanti
https://getcomposer.org/doc/04-schema.md#repositories

Ça veut donc dire qu’on peut très bien avoir notre git et mirorer simplement 
spip/spip sur github, ce qui n’est pas la mort
Après la question est donc de ce qu’on veut faire, de ce qu’on a l’energie de 
faire, de si on préfère se faire hoster par le grand 
capital-que-quand-même-finalement-ils-sont-gentils on si on a encore un petit 
peu d’idéaux etc…

(ou alors j’ai pas bon ?)

Des bises en tout cas
(c’est le seul truc qui marche encore un peu)

--
Cédric
Le 9 août 2019 à 02:09 +0200, Bruno Bergot , a écrit :
> Hop,
>
> Le 07/08/2019 à 16:21, RastaPopoulos a écrit :
> >
> > Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
> > CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
> > json etc), il ne sait installé QUE ce qui est pris en charge par le
> > dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
> > DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
> > l'instance officielle).
>
> Merci à Rasta de rappeler ce point qui pourtant était bien mis en avant
> dans l'article du blog à ce sujet :
>
> https://blog.spip.net/Composer-et-SPIP-sont-dans-un-bateau.html
>
> "Composer par défaut, sans autre configuration, utilise le site
> Packagist.org. Ce site, qui utilise l’outil libre Packagist, ne sait
> obtenir les sources avec les zips que depuis github.com ou gitlab.com
> (ces instances là précisément)."
>
> "De la sorte, aucune configuration supplémentaire n’est nécessaire pour
> les utilisatrices ou utilisateurs. Mais cela implique de déposer les
> sources sur github.com ou gitlab.com."
>
>
> Le 08/08/2019 à 14:45, nicod_ a écrit :
> > J'ai peur qu'on se retrouve soit avec des PR et des tickets des deux
> > côtés, soit que ce ne soit pas compréhensible, et obligerait à avoir des
> > comptes à plusieurs endroits.
> > Tickets et PR c'est quand même étroitement lié, pour moi ça devrait être
> > centralisé.
>
> Même si je pense qu'une seule forge doit suffire, on peut très bien
> utiliser un miroir sur github sans y accepter les PR, ça se configure
> dans le repo de chaque projet du core et zou. Ainsi on évite le problème
> des PRs déposées dans plusieurs endroits.
>
> Le 07/08/2019 à 16:21, RastaPopoulos a écrit :
> > Et du coup là : si on passe nos tickets sur Github, est-ce qu'il est
> > facile de tous les exporter un jour pour les déplacer ailleurs si on
> > veut partir ? Si oui alors ok, pas plus de problème que pour le code
> > sous Git. Sinon il faut réfléchir.
>
> J'ai souvenir de discussions (certainement en off) à ce sujet, et "on" a
> déjà un plan pour ça : mise en place d'une instance gitlab perso (donc
> sur une des machines de la communauté), qui par le biais de l'API github
> ferait des "backups" réguliers des tickets pour les garder au chaud
> *chez nous*.
>
> Le 08/08/2019 à 17:53, cam.la...@azerttyu.net a écrit :
> > Salut
> >
> > Sur les suggestions de question, pour la partie Github, je
> > reformulerai en "passer définitivement sur cette plateforme".
> > * Les options de bascule sont plus simple pour aller vers Github que
> > depuis Github. A mon sens il n'est pas pertinent d'avoir l'espoir d'en
> > revenir facilement.
>
> Je ne crois pas, de ce que j'en ai lu, on peut très bien migrer un
> projet complet (code, tickets, wikis, etc) de github vers une instance
> gitlab.
>
> > * Pour la partie backup, c'est une sous question. Il faut aussi
> > identifier qui voudrait s'en occuper. Bien que très importante on
> > enlève une grande partie de l’intérêt à maintenir une forge
> > communautaire. En l'état à titre personnel cela ne m'intéresse pas de
> > faire ce service.
>
> C'est noté :)
>
> > Concernant gitea il ne faut pas oublier redmine, c'est lui qui
> > centralise les tickets. Gitea a cette option mais je ne l'ai pas
> > activé du fait de l'existant fonctionnel.
>
> Amha, redmine est appelé à disparaître, les tickets doivent être sur la
> forge principale, quelle qu'elle soit.
>
> >
> > Autres points généraux :
> > * Le passage à github fera perdre l'historique vu que la numérotation
> > sera nouvelle.
>
> L'historique de quoi ?
>
> Si on parle des commits, le passage de svn à git "assure" déjà cette perte.
>
> Si on parle des tickets, ça nous est déjà arrivé lors de la migration de
> trac vers redmine (de mémoire), et il y a peut-être des solutions pour
> mapper les numéros de tickets redmine VS git/hub/lab/tea, une recherche
> rapide permet de trouver ceci :
>
> - https://github.com/IQSS/redmine2github &
> https://blogs.harvard.edu/rprasad/2014/07/10/moving-from-redmine-to-github-issues/
> - utilisé par QGIS ici
> 

Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-08 Par sujet Bruno Bergot

Hop,

Le 07/08/2019 à 16:21, RastaPopoulos a écrit :


Composer sait dialoguer avec plusieurs plateformes, mais par défaut SANS
CONFIGURATION à demander aux utilisateurs (sans rien ajouter dans des
json etc), il ne sait installé QUE ce qui est pris en charge par le
dépôt officiel de base Packagist.org, et ce dépôt reconnait tel quel que
DEUX choses : github.com et gitlab.com (pas LES Gitlab : juste
l'instance officielle).


Merci à Rasta de rappeler ce point qui pourtant était bien mis en avant 
dans l'article du blog à ce sujet :


https://blog.spip.net/Composer-et-SPIP-sont-dans-un-bateau.html

"Composer par défaut, sans autre configuration, utilise le site 
Packagist.org. Ce site, qui utilise l’outil libre Packagist, ne sait 
obtenir les sources avec les zips que depuis github.com ou gitlab.com 
(ces instances là précisément)."


"De la sorte, aucune configuration supplémentaire n’est nécessaire pour 
les utilisatrices ou utilisateurs. Mais cela implique de déposer les 
sources sur github.com ou gitlab.com."



Le 08/08/2019 à 14:45, nicod_ a écrit :
J'ai peur qu'on se retrouve soit avec des PR et des tickets des deux 
côtés, soit que ce ne soit pas compréhensible, et obligerait à avoir des 
comptes à plusieurs endroits.
Tickets et PR c'est quand même étroitement lié, pour moi ça devrait être 
centralisé.


Même si je pense qu'une seule forge doit suffire, on peut très bien 
utiliser un miroir sur github sans y accepter les PR, ça se configure 
dans le repo de chaque projet du core et zou. Ainsi on évite le problème 
des PRs déposées dans plusieurs endroits.


Le 07/08/2019 à 16:21, RastaPopoulos a écrit :

Et du coup là : si on passe nos tickets sur Github, est-ce qu'il est
facile de tous les exporter un jour pour les déplacer ailleurs si on
veut partir ? Si oui alors ok, pas plus de problème que pour le code
sous Git. Sinon il faut réfléchir.


J'ai souvenir de discussions (certainement en off) à ce sujet, et "on" a 
déjà un plan pour ça : mise en place d'une instance gitlab perso (donc 
sur une des machines de la communauté), qui par le biais de l'API github 
ferait des "backups" réguliers des tickets pour les garder au chaud 
*chez nous*.


Le 08/08/2019 à 17:53, cam.la...@azerttyu.net a écrit :

Salut

Sur les suggestions de question, pour la partie Github, je
reformulerai en "passer définitivement sur cette plateforme".
* Les options de bascule sont plus simple pour aller vers Github que
depuis Github. A mon sens il n'est pas pertinent d'avoir l'espoir d'en
revenir facilement.


Je ne crois pas, de ce que j'en ai lu, on peut très bien migrer un 
projet complet (code, tickets, wikis, etc) de github vers une instance 
gitlab.



* Pour la partie backup, c'est une sous question. Il faut aussi
identifier qui voudrait s'en occuper. Bien que très importante on
enlève une grande partie de l’intérêt à maintenir une forge
communautaire. En l'état à titre personnel cela ne m'intéresse pas de
faire ce service.


C'est noté :)


Concernant gitea il ne faut pas oublier redmine, c'est lui qui
centralise les tickets. Gitea a cette option mais je ne l'ai pas
activé du fait de l'existant fonctionnel.


Amha, redmine est appelé à disparaître, les tickets doivent être sur la 
forge principale, quelle qu'elle soit.




Autres points généraux :
* Le passage à github fera perdre l'historique vu que la numérotation
sera nouvelle.


L'historique de quoi ?

Si on parle des commits, le passage de svn à git "assure" déjà cette perte.

Si on parle des tickets, ça nous est déjà arrivé lors de la migration de 
trac vers redmine (de mémoire), et il y a peut-être des solutions pour 
mapper les numéros de tickets redmine VS git/hub/lab/tea, une recherche 
rapide permet de trouver ceci :


- https://github.com/IQSS/redmine2github & 
https://blogs.harvard.edu/rprasad/2014/07/10/moving-from-redmine-to-github-issues/
- utilisé par QGIS ici 
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/141




* Les PR ne se résume pas à être valider par une interface graphique,
git propose de base la possibilité de gérer du multi source dont les
mails. Cela demande un peu de travail, mais dans la pratique c'est
rare d'utiliser le bouton valider si on fait une revue correcte du
code proposé.


Un des gros avantages des forges actuelles est justement de permettre 
aux gens de proposer des patchs en mode "clic & play", je doute 
fortement qu'on arrive à motiver les contributions et leur intégration 
par l'équipe si on passe par des patchs envoyés en pièces jointes dans 
des mails :\


Quant au bouton "valider", il est certainement plus utilisé que tu ne le 
crois, surtout quand le patch ne concerne qu'une coquille ou une 
pétouille. À propos de la revue de code, on a il me semble acté (ou au 
moins à moitié) qu'il serait bien que toutes les modifications (même 
celles des membres de l'équipe) passent par une PR ayant reçu au moins 
un ou deux "+1" des autres membres.



* Pour les utilisateurs github, il est possible de se connecter à

Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-08 Par sujet cam.la...@azerttyu.net
Salut

Sur les suggestions de question, pour la partie Github, je
reformulerai en "passer définitivement sur cette plateforme".
* Les options de bascule sont plus simple pour aller vers Github que
depuis Github. A mon sens il n'est pas pertinent d'avoir l'espoir d'en
revenir facilement.
* Pour la partie backup, c'est une sous question. Il faut aussi
identifier qui voudrait s'en occuper. Bien que très importante on
enlève une grande partie de l’intérêt à maintenir une forge
communautaire. En l'état à titre personnel cela ne m'intéresse pas de
faire ce service.

Concernant gitlab je ne suis pas sur que ce soit, comme tu le notes, à
considérer. Des personnes se sont exprimées pour dire l'apprécier mais
personne pour en faire le suivi. Donc cela risque d'être compliqué si
cette solution est retenue et qu'il n'y a personne pour le prendre en
charge.

Concernant gitea il ne faut pas oublier redmine, c'est lui qui
centralise les tickets. Gitea a cette option mais je ne l'ai pas
activé du fait de l'existant fonctionnel.

Autres points généraux :
* Le passage à github fera perdre l'historique vu que la numérotation
sera nouvelle.
* Les PR ne se résume pas à être valider par une interface graphique,
git propose de base la possibilité de gérer du multi source dont les
mails. Cela demande un peu de travail, mais dans la pratique c'est
rare d'utiliser le bouton valider si on fait une revue correcte du
code proposé.
* Pour les utilisateurs github, il est possible de se connecter à
gitea sans créer de compte, l'oauth est actif. Cela ne devrai pas
changer les pratiques de ces personnes qui utilisent les app (Ci/...)
de github.
* Même une fois le choix défini on aura toujours le problème de la nomenclature

Km

Le jeu. 8 août 2019 à 17:10, Eric Lupinacci  a écrit :
>
> Yop,
>
>
>
> Le jeu. 8 août 2019 à 15:53, JLuc  a écrit :
>>
>> Le 08/08/2019 à 14:45, nicod_ a écrit :
>> > J'aimerais vraiment que James nous assiste sur ce coup là, pour éviter un 
>> > piège qu'on ne verrait pas.
>>
>> Tant qu'à "mettre les pieds dans le plat et appeler un chat un chat",
>> la sporadique et évanescente "présence" de James n'est elle pas aussi un 
>> problème ?
>
>
> Je ne suis pas sur du tout que ce soit le sujet du moment.
> Cédric a bien expliqué qu'il y avait deux points à traiter même si ces deux 
> points ont une intersection non nulle.
>
> Il nous faut d'abord une forge Git.
> Il y en a 3 possibles :
> - Github où tout le monde a un compte ou presque et qui nous évite pas mal de 
> soucis d'administration mais c'est Github et il faudra de fait avoir au moins 
> un backup pour les tickets
> - Gitlab qui est proche mais j'ai l'impression qu'il na pas trop d'intérêt 
> par rapport à Github
> - Gitea qui pose tel quel un souci avec Composer mais qui est aujourd'hui 
> fortement avancé pour intégrer l'ensemble de la Zone et de SPIP avec les 
> travaux de Camille. On peut colmater le problème de composer avec un 
> mirroring Github qui n'est pas totalement satisfaisant car on multiplierait 
> les sources de PR (ça peut aussi se régler par une explication non ?)
>
> Quand on voit le thread actuel, les précédents, car il y en a déjà eu sur le 
> même sujet avec les mêmes débats, on a l'impression qu'on en sortira jamais 
> et que rien ne réconciliera les avis divergents. il y a des pros pour chaque 
> solution, des réticents pour chaque solution et pas de solution miracle qui 
> réconcilie tout le monde.
>
> Donc je ne vois qu'une seule chose pour sortir de cette solution : lancer un 
> sondage, définir un quorum, voter et ensuite accepter la décision et la 
> mettre tous en place.
> La solution est à mon avis dans le fait de jouer en équipe pour sortir de ce 
> trou !
>
> Donc êtes vous d'accord qu'on parte dans ce processus pour en finir avec ce 
> pourrissement ?
> Première proposition pour le sondage (pièce à casser bien sur)  :
>
> - GitHub pour la Zone et SPIP avec solution de backup pour les tickets ou un 
> scénario de basculement à terme sur Gitea ?
> - Gitlab pour la Zone et SPIP (je sais pas si il faut prévoir autre chose ou 
> si d'ailleurs ce choix est à considérer) ?
> - Gitea pour la Zone et SPIP avec un scénario de basculement si le 
> fonctionnement avec Composer, l'administration et le couple (Ticket,PR) pose 
> problème ?
>
> ++
> Eric
>
>
>
>
> 
> spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-08 Par sujet Eric Lupinacci
Yop,



Le jeu. 8 août 2019 à 15:53, JLuc  a écrit :

> Le 08/08/2019 à 14:45, nicod_ a écrit :
> > J'aimerais vraiment que James nous assiste sur ce coup là, pour éviter
> un piège qu'on ne verrait pas.
>
> Tant qu'à "mettre les pieds dans le plat et appeler un chat un chat",
> la sporadique et évanescente "présence" de James n'est elle pas aussi un
> problème ?
>

Je ne suis pas sur du tout que ce soit le sujet du moment.
Cédric a bien expliqué qu'il y avait deux points à traiter même si ces deux
points ont une intersection non nulle.

Il nous faut d'abord une forge Git.
Il y en a 3 possibles :
- Github où tout le monde a un compte ou presque et qui nous évite pas mal
de soucis d'administration mais c'est Github et il faudra de fait avoir au
moins un backup pour les tickets
- Gitlab qui est proche mais j'ai l'impression qu'il na pas trop d'intérêt
par rapport à Github
- Gitea qui pose tel quel un souci avec Composer mais qui est aujourd'hui
fortement avancé pour intégrer l'ensemble de la Zone et de SPIP avec les
travaux de Camille. On peut colmater le problème de composer avec un
mirroring Github qui n'est pas totalement satisfaisant car on multiplierait
les sources de PR (ça peut aussi se régler par une explication non ?)

Quand on voit le thread actuel, les précédents, car il y en a déjà eu sur
le même sujet avec les mêmes débats, on a l'impression qu'on en sortira
jamais et que rien ne réconciliera les avis divergents. il y a des pros
pour chaque solution, des réticents pour chaque solution et pas de solution
miracle qui réconcilie tout le monde.

Donc je ne vois qu'une seule chose pour sortir de cette solution : lancer
un sondage, définir un quorum, voter et ensuite accepter la décision et la
mettre tous en place.
La solution est à mon avis dans le fait de jouer en équipe pour sortir de
ce trou !

Donc êtes vous d'accord qu'on parte dans ce processus pour en finir avec ce
pourrissement ?
Première proposition pour le sondage (pièce à casser bien sur)  :

- GitHub pour la Zone et SPIP avec solution de backup pour les tickets ou
un scénario de basculement à terme sur Gitea ?
- Gitlab pour la Zone et SPIP (je sais pas si il faut prévoir autre chose
ou si d'ailleurs ce choix est à considérer) ?
- Gitea pour la Zone et SPIP avec un scénario de basculement si le
fonctionnement avec Composer, l'administration et le couple (Ticket,PR)
pose problème ?

++
Eric

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-08 Par sujet JLuc

Le 08/08/2019 à 14:45, nicod_ a écrit :

J'aimerais vraiment que James nous assiste sur ce coup là, pour éviter un piège 
qu'on ne verrait pas.


Tant qu'à "mettre les pieds dans le plat et appeler un chat un chat",
la sporadique et évanescente "présence" de James n'est elle pas aussi un 
problème ?

James, "si tu existes", comment est-ce que tes projets composeriens
composent ils avec ta non participation avec les questions réponses et débats ?

JL


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-08 Par sujet nicod_

Le 07/08/2019 à 09:33, Cerdic a écrit :

Parce qu’on pourrait très bien avoir notre dépôt principal sur un Gitea
ou un Gitlab SPIP (avec tout ce qui va bien, les tickets etc) et juste
un mirroring automatique vers Github, tant pour la publication vers
Packagist que pour la visibilité et les PR.


J'ai peur qu'on se retrouve soit avec des PR et des tickets des deux 
côtés, soit que ce ne soit pas compréhensible, et obligerait à avoir des 
comptes à plusieurs endroits.
Tickets et PR c'est quand même étroitement lié, pour moi ça devrait être 
centralisé.



Je crois qu’on est tous à peu près OK pour composer, en faisant
confiance à ceux qui on vraiment travaillé sur le sujet, parce que d’un
peu loin on voit pas très bien toutes les implications et les
contraintes qui vont venir avec.


J'aimerais vraiment que James nous assiste sur ce coup là, pour éviter 
un piège qu'on ne verrait pas.



Le 07/08/2019 à 16:21, RastaPopoulos a écrit :

Ensuite il y a la question de maintenir plusieurs dépôts ou pas (un
principal et un miroir).

Moi aussi j'étais plutôt partant pour maintenir notre truc, et avoir un
miroir uniquement lecture sur Github. Mais après les débats lors de la
formation avec James, il en ressortait que :

1) On galère déjà à maintenir de nombreux outils, et nous sommes peu
nombreux (vraiment). Là une forge c'est un gros truc, de l'admin sys,
pas du SPIP (c'est pas comme maintenir Contrib, spip.net, etc). Et très
probablement ça sera sur les épaules d'UNE personne unique (parmi le
déjà peu qu'on est, il y a encore moins d'admin sys), allez deux pour
être gentil. Et quand il y aura un soucis, ça sera de nouveau difficile.
A-t-on vraiment besoin de maintenir 100% des choses ? Avec Git si jamais
il y a un soucis de droit, de coupure, etc, on peut toujours déplacer
ailleurs en très peu de temps !


Absolument +1
Sur Github/Gitlab, zéro maintenance, zéro coût pour nous.



2) A-t-on vraiment envie de gérer des PR *en plusieurs endroits* ? La
majorité des devs SPIP ont déjà un compte Github. Un des buts de
Composer et de s'insérer dans l'écosystème c'est d'inclure plus
facilement des nouvelles personnes. On ne se leurre pas, on va pas
attirer des milliers de gens, mais la majorité des quelques devs NON
CONNUS qui pourraient proposer des modifs, doivent avoir un compte
Github. Est-ce qu'on veut vraiment obliger les gens à créer un compte
sur notre forge à nous pour proposer des modifs ? (non) Et si on a des
PR en plusieurs endroits, ça va vite être très chiants à maintenir, à
savoir quoi et où relire à temps. Il semblerait mieux de tout
centraliser et de n'avoir qu'un seul lieu où proposer des modifs. Donc
Github.com.


Absolument +1 aussi pour la centralisation des PR, et tickets à un seul 
endroit, les deux sont liés.


--
nicod_

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-05 Par sujet cam.la...@azerttyu.net
Bonjour

Nouvelles mises à jour de la forge git.spip.net avec la version 1.9.0

On peut noter les améliorations suivantes :
* le support de git-note (qui peut être intéressant pour afficher les notes svn)
* amélioration du moteur de recherche pour les commits avec de
nouveaux filtres (author:, committer:, after:, et before:)
* la possibilité d'importer des dépôts externe avec les tickets, les PR, ...

Il y a d'autres améliorations je vous invite à consulter le blog gitea :
https://blog.gitea.io/2019/07/gitea-1.9.0-is-released/

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-08-05 Par sujet cam.la...@azerttyu.net
Bonjour Gildas

>> Nouvelles mises à jour avec divers correctifs avec les version 1.8.2
>> et 1.8.3 (j'ai pris un peu de retard sur le suivi)
>
>
> Merci pour le suivi. Je connaissais son aîné, mais je n'avais pas eu 
> l'occasion de me pencher sur la fourche...

Je dirais que la différence entre gogs et gitea est que le projet est
plus actif et collectif

> Dites-moi, si je comprends bien, la communauté Spip est en train de passer à 
> Git et a choisi gitea ?

Non et oui. Depuis un moment il y a une volonté de migrer vers git. De
mon coté j'ai testé diverses forges et j'ai retenu gitea à force
d'essais infructueux.
Est ce qu'au final c'est gitea, github, gitlab,  qui restera je
n'en ai aucune idée.
De mon coté je pousse gitea malgré ses imperfections car je trouve les
autres solutions inadaptées. Dans tous les cas je ne peux pas parler
au nom de la communauté.

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-06-24 Par sujet Gildas Cotomale
Le lun. 24 juin 2019 18:51, cam.lafit@ a écrit :

> Bonjour
>

Bonsoir,

>
> Nouvelles mises à jour avec divers correctifs avec les version 1.8.2
> et 1.8.3 (j'ai pris un peu de retard sur le suivi)
>

Merci pour le suivi. Je connaissais son aîné, mais je n'avais pas eu
l'occasion de me pencher sur la fourche...

Dites-moi, si je comprends bien, la communauté Spip est en train de passer
à Git et a choisi gitea ?

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-06-24 Par sujet JLuc

Le 24/06/2019 à 19:01, Franck a écrit :

Merci azerttyu pour le boulot ! 

Ouais merci ce que j'avais qualifié de priorités marche super bien depuis 
quelques semaines :-)
JL


De : cam.la...@azerttyu.net 
Bonjour Nouvelles mises à jour avec divers correctifs avec les version 1.8.2 et 
1.8.3



spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-06-24 Par sujet Franck
Merci azerttyu pour le boulot ! 
Franck

-Message d'origine-
De : cam.la...@azerttyu.net  
Envoyé : lundi 24 juin 2019 18:50
À : SPIP-dev SPIP ; spip-zone 
Objet : Re: [SPIP Zone] Mise à jour git.spip.net

Bonjour

Nouvelles mises à jour avec divers correctifs avec les version 1.8.2 et 1.8.3 
(j'ai pris un peu de retard sur le suivi) 
https://blog.gitea.io/2019/05/gitea-1.8.2-is-released/
https://blog.gitea.io/2019/06/gitea-1.8.3-is-released/

Note : le pied de page n'est toujours pas mis à jour et indique toujours 1.8.0

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-06-24 Par sujet cam.la...@azerttyu.net
Bonjour

Nouvelles mises à jour avec divers correctifs avec les version 1.8.2
et 1.8.3 (j'ai pris un peu de retard sur le suivi)
https://blog.gitea.io/2019/05/gitea-1.8.2-is-released/
https://blog.gitea.io/2019/06/gitea-1.8.3-is-released/

Note : le pied de page n'est toujours pas mis à jour et indique toujours 1.8.0

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone


Re: [SPIP Zone] Mise à jour git.spip.net

2019-05-14 Par sujet cam.la...@azerttyu.net
Bonjour

Nouvelle mise à jour de sécurité avec la version 1.8.1
https://blog.gitea.io/2019/05/gitea-1.8.1-is-released/

Note : le pied de page n'est pas mis à jour et indique toujours 1.8.0
(cela semble un oubli des dev)

Km

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone