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

2019-10-02 Par sujet Gildas Cotomale
Le mer. 2 oct. 2019 18:18, cam.lafit@ a écrit :

> Bonjour
>

Ciao tuti

>
> Pour information :
> phabricator a été testé. Il ne correspond pas à nos usages entre autre
> en obligeant à nommer les projets avec des trigrammes. Ce qui est
> compliqué et inadapté à notre volumétrie. [...]


Wahooo ! Je me rends compte qu'on ne se rend pas compte du taf que t'as
abattu.
On devrait franchement basculer pour de bon ; je ne vois plus ce qu'on
attend (sauf la forge maison ou messie)

>
>

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


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

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

Pour information :
phabricator a été testé. Il ne correspond pas à nos usages entre autre
en obligeant à nommer les projets avec des trigrammes. Ce qui est
compliqué et inadapté à notre volumétrie. Le projet est porté par
wikipedia entre autre mais on voit que leur méthodologie et besoin
n'ont que très peu de rapport avec nous.

Km

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


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

2019-10-02 Par sujet Gildas Cotomale
Hello,

J'avais pas suivi les échanges entre temps, mais je voter pour gitea : ça
fait largement le boulot par rapport à nos besoins et n'a rien à envier aux
mastodontes (...hub/lab même si je ne juge pas que Go soit meilleur que
Ruby haha) ; et attention, je parle des besoins-et-usages
identifiés-décrits pas juste de l'admin (jamais eu de souci avec mes
instances gitlab, mais le contexte --nombre de
projets/groupes/utilisateurs-- et les ressources  allouées ne sont
certainement pas pareils)

--

J'en profite pour quelque petit rappel/remarque après avoir vu que certains
entendent les chants de la mauvaise sirène :o

En utilisant Svn, on a évité d'aller chez : "CloudForge" <
http://www.cloudforge.com/> ; "GForge" 
; "SourceForge"  ; "RhodeCode" <
https://rhodecode.com/> ; "CodeBase"  ;
"Assembla"  ; "Helix TeamHub" <
http://www.perforce.com/> ;
En passant à Git, il faut éviter ces mêmes services (ceux qui supportent
aussi du Git) et similaires : "Github"  ; "Bitbucket" <
https://bitbucket.org/> ; "YouTrack" ; "Codeplex" ; etc.

Pour une forge auto-gérée, le constat est que Trac ne fait pas l'affaire
(sinon il existe aussi pour du Git...) et que GitLab CE (ou une solution
basée sur Ruby comme Github justement) est trop lourd. Du coup, il ne reste
que Gitea (écrit en Go et ayant interface/fonctionnalités proches de
Github) ou peut-être : "Phabricator" 
(c'est écrit en PHP héhé) ; "gogs"  (mais bon, gitea est
sa fourche avec plus de fonctionnalités <
https://docs.gitea.io/en-us/comparison/>) "Gitblit" 
(côté légèreté j'ai des aprioris vu que c'est en Java, mais bon

Si c'est pour des soucis de maintenance et qu'il y a vraiment le besoin de
faire héberger la forge, il y a des offres plus en accord avec les valeurs
défendues (comme "OurProject"  ou "Savannah" <
https://savannah.gnu.org/> ou encore "gitorious" 
autrefois) : "OpenHub"  ; "OSDN" <
https://osdn.net/> ; "Gitlab.com"  ou
"Framagit" 
On peut également considérer d'être porté par : "SEUL" <
https://www.seul.org/> ; "OW2"  ; "TuxFamily" <
http://projects.tuxfamily.org/?do=allgroups> ; etc.

C'est tout. Et désolé pour l'inventert à la Prévaire.

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


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

2019-09-16 Par sujet Eric Lupinacci
Re,

Le lun. 16 sept. 2019 à 12:04, Maïeul Rouquette  a
écrit :

>
> vu que c'est prématuré, alors non.
>
>
Et ça risque de le rester longtemps...
Si on se résume :
- on a un thread lancé par Rasta sur les organisations de la future...
forge git : plusieurs propositions, des questions non répondues et pas de
décision encore. Camille continue d'avoir le c.. entre deux chaises puisque
l'état actuel n'est pas encore l'état final qui n'est pas connu...
- on a un thread lancé par Cedric qui résume les avantages et inconvénients
des différentes alternatives de forge : gitea (git.spip.net), github et
gitlab et un résumé sur les liens avec Composer. Là encore pas de décision,
la forge git de spip est sous Gitea, Camille fait des mises à jour mais il
est possible que tout ça parte à la poubelle un jour.

Voilà l'état pas grandiose dans lequel on est, et je rajoute que si on se
décide aujourd'hui cela ne concernera que SPIP et plugins-dist. Donc
l'entropie ne fera qu'augmenter car il faudra jongler entre plusieurs
forges motorisées par différents outils : le pied !

Franchement, je suis de plus en plus persuadé que cette dichotomie est une
connerie qui aura un effet plus négatif que positif : on devrait tout
migrer d'un coup de SVN à Git.
D'ailleurs à ce propos, c'est l'un des intérêts de Github que de fournir un
outil desktop très simple et installable sur toutes les plateformes. On
peut faire du chekout / commit comme avant sans vraiment s'emmerder avec la
complexité de Git.
C'est aussi à prendre en compte !



> Mais en gros ma demande serait un article pour
> 1) migrer de zone vers git.spip.net
> 2) permettre le lien avec smart-paquet
>
>
Pour smart-paquets c'est une autre histoire.
Aujourd'hui, on recalcule tous les zips à partir d'une copie de travail SVN
même ceux qui viennent de Git (externals).
Pourtant, ceux qui sont sous git propose déjà un zip tout fait sur la forge.
Avec les modifications que j'ai fait récemment sur Plugins SPIP pour aller
chercher les commits de github et les afficher je pourrais directement
indexer le zip github et donc ne plus rien avoir à faire comme zip dans
Smart-Paquets.

Si on extrapole, en ayant toute la zone sous github ou gitea on
s'affranchirait complètement de l'empaquetage de smart-paquets.
Mais ce n'est pas pour ça qu'on aurait plus besoin de smart-paquets !
On aurait besoin d'un smart-référentiel en quelque sorte pour construire
les éléments nécessaires à la constitution du référentiel des plugins
servant à Plugins et un jour Contrib.
Mais ça serait beaucoup plus satisfaisant à mon avis car justement on
arrêterait de mélanger les éléments de paquet et ceux de référentiel
surtout en vue de Composer.

Je pense qu'il faut aller dans cette voie le plus vite possible et donc
tout migrer d'un coup spip et le reste.

++
Eric

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


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

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

> Je ne sais pas si j'ai bien compris où on en était ou pas mais je viens 
> d'aller sur git.spip.net pour voir si il y avait moyen de faire une 
> pull-request.
> J'ai rien compris, pas trouvé donc bref passons c'est un autre sujet et le 
> problème est chez moi.

Qu'est ce que tu n'as pas compris ?
Il y a un crayon sur chaque page de code qui permet de faire le fork
en direct et faire une PR. On est sur le même fonctionnement que
github.
A noter qu'une modification d'une page correspond dans ce cas à un PR.
Gitea ne permet pas encore (à ma connaissance) de faire un PR en
édition web de plusieurs fichiers. J'ai vu que cette fonctionnalité
était passé en phase de teste assez recemment chez github.

> Mais ça m'a permis de naviguer sur le site.

:)

> Déjà la liste des organisations : je vois qu'il y a toujours squelettes qui 
> n'a pas de sens.

Un oubli de ma part , c'est corrigé.
Je me dit qu'on pourrait créer une organisation bac_a_sable open bar
et sans impact

> Ensuite quand je vais dans l'organisation SPIP je ne trouve pas que SPIP et 
> ses plugins-dist mais pleins d'autres plugins. Est ce transitoire parce que 
> c'est pas fini ou un bug de gitea ou autre ?

C'est un bogue que tu m'avais remonté. J'avais "résolu" en faisant un
rafraichissement du serveur mais cela ne semble pas fonctionner.
On peut voir que les liens renvoit bien vers l'oganisation qui va
bien, on a bien un bogue d'affichage. J'ai ouvert un ticket à ce
sujet.
https://github.com/go-gitea/gitea/issues/8195


> Après franchement, à tout mettre ensemble comme ça, on se retrouve avec le 
> core SPIP noyé parmi les autres plugins dans un ordre alphabétique et on peut 
> pas dire que ce soit l'ergonomie du siècle...

Oui du coup ça fait gros listing imbuvable. L'orga SPIP contient bien :
* SPIP
* ses 2 déclinaisons core et prive (la nouvelle structure de composer)
* les plugins-dist

> Il va quand même falloir me convaincre de l'intérêt de minimiser les 
> organisations quand on sait que dessous tout est en vrac !

bug comme dit plus haut.
Pour le reste on a déjà un sujet ouvert en cours.

> Enfin, le truc aussi gênant c'est que c'est lent, très lent.

Le serveur n'a pas été dimensionné pour du plein régime. Je vais
augmenter ses ressources. Pour rappel pour le moment le projet git
repose uniquement sur mon infra et mon budget.
Donc pour le moment j'équilibre en conséquence. Je n'augmenterai pas
les coûts si comme on me le répète trop souvent ce qui est fait sert à
rien.

> Alors franchement ça me gonfle.
> Ca me gonfle d'en être là après tant de mois.
> De voir certains s'exténuer sans support pour un résultat qui malheureusement 
> n'est pas encore au niveau de ce qu'on peut attendre.
> Alors au lieu de se balancer des trolls à la figure parce que l'un veut si et 
> l'autre autre chose et que si il l'a pas il participera pas, je pense qu'on 
> serait plus avisé de se retrousser les manches pour d'une part décider sans 
> retour notre orientation et la mettre en place, et ce, dans un laps de temps 
> raisonnable. Et on a tous un boulot et on a tous du temps de libre, on doit 
> donc pouvoir s'accorder un peu pour s'organiser.
> C'est franchement devenu pour moi insupportable de devoir attendre des mois 
> pour faire un pas de nain.

bienvenue au club.

Km

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


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

2019-09-14 Par sujet JLuc

Le 14/09/2019 à 10:44, Eric Lupinacci a écrit :
Je ne sais pas si j'ai bien compris où on en était ou pas mais je viens d'aller sur git.spip.net  
pour voir si il y avait moyen de faire une pull-request.

J'ai rien compris, pas trouvé donc bref passons c'est un autre sujet et le 
problème est chez moi.


Bah pas que chez toi.

J'étais tombé sur cette difficulté et trouvé ça bien complexe.

Quelques mails échangés sur les listes avaient ensuite
pour certains confirmé ces notes (avec de menues variantes parfois)
ou au contraire un peu embrouillé les pistes ("chez moi" en tout cas)...

J'avais documenté la compréhension issue de cette démarche :
https://contrib.spip.net/Proposer-un-patch-via-git-spip-net
Faudrait encore synthétiser les possibles, bien tester et documenter.
Mais ça suppose de sortir de l'incertitude  / l'avenir de spip sur git.

Ya aussi cette page collective sur contrib : https://contrib.spip.net/Git
et celle ci où c'est Tcharlss qui témoigne :
https://contrib.spip.net/GIT-faire-des-pull-requests-propositions-de

JLuc


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


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

2019-09-14 Par sujet Eric Lupinacci
Hello,



Le mar. 10 sept. 2019 à 12:16, cam.la...@azerttyu.net <
cam.la...@azerttyu.net> a écrit :

> 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"
>

Je ne sais pas si j'ai bien compris où on en était ou pas mais je viens
d'aller sur git.spip.net pour voir si il y avait moyen de faire une
pull-request.
J'ai rien compris, pas trouvé donc bref passons c'est un autre sujet et le
problème est chez moi.
Mais ça m'a permis de naviguer sur le site.

Déjà la liste des organisations : je vois qu'il y a toujours squelettes qui
n'a pas de sens.
Ensuite quand je vais dans l'organisation SPIP je ne trouve pas que SPIP et
ses plugins-dist mais pleins d'autres plugins. Est ce transitoire parce que
c'est pas fini ou un bug de gitea ou autre ?
Après franchement, à tout mettre ensemble comme ça, on se retrouve avec le
core SPIP noyé parmi les autres plugins dans un ordre alphabétique et on
peut pas dire que ce soit l'ergonomie du siècle...
Il va quand même falloir me convaincre de l'intérêt de minimiser les
organisations quand on sait que dessous tout est en vrac !

Enfin, le truc aussi gênant c'est que c'est lent, très lent.

Alors franchement ça me gonfle.
Ca me gonfle d'en être là après tant de mois.
De voir certains s'exténuer sans support pour un résultat qui
malheureusement n'est pas encore au niveau de ce qu'on peut attendre.
Alors au lieu de se balancer des trolls à la figure parce que l'un veut si
et l'autre autre chose et que si il l'a pas il participera pas, je pense
qu'on serait plus avisé de se retrousser les manches pour d'une part
décider sans retour notre orientation et la mettre en place, et ce, dans un
laps de temps raisonnable. Et on a tous un boulot et on a tous du temps de
libre, on doit donc pouvoir s'accorder un peu pour s'organiser.
C'est franchement devenu pour moi insupportable de devoir attendre des mois
pour faire un pas de nain.

++
Eric

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


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

2019-09-10 Par sujet Eric Lupinacci
Hello,



Le mar. 10 sept. 2019 à 12:16, cam.la...@azerttyu.net <
cam.la...@azerttyu.net> a écrit :

> * L'organisation "contrib" regroupe ce qui ne peut être dans "plugin"
>
>
Je trouve que c'est un fourre-tout.
Je milite toujours pour qu'on sépare la galaxie SPIP de ces contribs, je ne
comprends pas l'argument sur le nombre d'organisations.



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

C'est quand et comment qu'on clos toutes ces discussions ouvertes ?
Franchement c'est pénible, très pénible (mais c'est pas de ton fait ;-)).

++
Eric

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


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

2019-08-10 Par sujet Eric Lupinacci
Re,

Le sam. 10 août 2019 à 11:43, Cerdic  a écrit :

> Mais si « on » met la même énergie à tout faire marcher qu’à râler je n’ai
> pas de toute que tout ira bien.
>
>
Aucun doute non plus.

++
Eric

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


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

2019-08-09 Par sujet Eric Lupinacci
Yo,


Le ven. 9 août 2019 à 20:50, Matthieu Marcillaud  a
écrit :

> Le 07/08/2019 à 14:12, cam.la...@azerttyu.net a écrit :
> > Salut
>
> Il reste néanmoins un souci de lenteur d’affichage, sur certaines pages
> particulièrement. Juste pour un petit exemple :
>
> - https://github.com/spip/SPIP/tree/master/ecrire (affichage
> relativement instantané)
> - https://git.spip.net/SPIP/spip/src/branch/master/ecrire (Page:
> 26262ms) (j’ai pas eu moins de 18s ici)
>
>
Le ven. 9 août 2019 à 20:49, RastaPopoulos  a
écrit :

>
> > 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.
>
> 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).
>

Non mais les gars là il faut arrêter à mon avis ces discussions et arrêter
d'alimenter ces threads qui n'en finissent pas de tourner autour du pot.
Je vous jure que j'ai relu des threads équivalents ces derniers mois.
Je pense qu'on a presque tout dit sur le sujet, on connait les + et les -
mais surement pas tout.

Donc svp dites clairement ce que vous voulez et basta.
Ca sera Github ou Gitea, il y aura des satisfaits et des mécontents voire
des indéfférents.
Tant pis, on passera outre et on l'acceptera tous une fois que ce sera
décidé et surtout que ça fonctionnera.

Alors SVP prononcez vous, franchement.

++
Eric

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


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

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

>> 2/ Composer donc
>> Qui impose de son côté des contraintes sur l’import Git, le découpage du 
>> core et d’autres petits tracas techniques que James saurait mieux expliquer. 
>> Rien d’insurmontable, mais aussi une migration vers Git un peu différente de 
>> ce qu’avait préparé Camille du coup dans le découpage - mais je comprends 
>> que dans les derniers travaux de Camille ça s’unifie.

J'ai oublié de préciser dans mon précédent courriel que les
contraintes du genre découpage ecrire, prive sont déjà opérationnelles
:
https://git.spip.net/SPIP/prive
https://git.spip.net/SPIP/ecrire

> Donc il faut choisir entre Gitea, Gitlab et Github, je suppose qu'il est 
> inutile d'envisager autre chose.
> Peut-on faire faire une liste de critères à analyser pour alimenter la 
> discussion ?

Pour partie ils vont être subjectifs difficile d'être factuel. Je vais
essayer de répondre à ces points, à d'autre de compléter pour avoir
une vision plus gloable
>
> - performances serveur
go plus rapide que ruby

> - facilité d'administration
équivalente (au finale peu utiliser une fois la configuration mise en place)

> - ergonomie de l'interface git
gitea propose la personnalisation  (cf l'ajout de la boussole)

> - gestion des tickets
équivalent
possibilité de déleguer à un autre gestionnaire avec gitea (par
exemple spip est branché sur le redmine)

> - open-source + ou -
gitea open source (+)
gitlab version mixte fermée (-)

> - API, langage source
gitea respect de l'api github (objectif)
code gitea plus lisible que celui de gitlab (go vs ruby et ancienneté du code)

> - intégration d'outils externes
Pour le cas de la CI je dirais que gitlab a de l'avance car ils ont
développé leurs propres outils gitlab-ci
Gitea réduit son écart avec drone.
A noter qu'en mode miroir on peut exploiter l'écosystème de github.
C'est par exemple le cas avec scrutinizer-ci qui est branche

Il est toujours possible d'utiliser jenkins, travis, ...
indifféremment avec les 2 forges

> - ... ?
- Maintenabilité système
Gitea une binaire go à remplacer
Gitlab fournit un mode omnibus

Le mode omnibus est un paquet qui commun à toutes les distributions
linux. De fait il ne cherche pas à respecter l'arborescence propre à
un OS et met ses fichiers comme il l'entend.
De ce que j'ai suivi cela s'est amélioré mais c'est/c'était compliqué
ensuite à maintenir quand ça casse.

J'ai eu une très mauvaise expérience de ce point de vue avec gitlab.

- Montée de version
Gitea est très facile à mettre à jour,
Gitlab fournit un  paquet boite noire

Km

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


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

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


> Je vais donc mettre les pieds dans le plat et appeler un chat un chat.
>
> 1/ Gitea vs autre chose
> Mais le choix de Gitea est uniquement fait sur des critères techniques, pour 
> faciliter l’admin sys, et non sur des critères d’utilisabilité ou de 
> fonctionnalités (peut-être aussi pour des contraintes liés à la synchro 
> svn-git, mais qui n’est plus à l’ordre du jour).

Désolé mais je vais être en désaccord :)
J'ai regardé et testé plusieurs forges gitolite, gitosis, gitlab,
phabricator, redmine et gitea. J'en oublie peut être d'autres.

Sur toutes les solutions testées gitea me semble le meilleurs compromis :
du point de vue technique:
* il s'installe et se met à jour facilement
* la présence des fichiers sont unifiés et n'a pas ce mode omnibus de
gitlab qui en met de partout
* le suivi/disponibilité des mainteneurs du projet

du point de vue utilisateur :
* la page d'accueil peut être personnalisée (pendant longtemps c'était
uniquement dans l'offre payant de gitlab)
* le support multilangue
* la personnalisation du theme (boussole qui sert à naviguer dans notre galaxie)
* le suivi/disponibilité des mainteneurs du projet (oui je me répete
car cela impacte aussi l'usage quotidien)

Si on avait voulu rester sur du pure technique facilement à maintenir
git over ssh c'était le mieux.

> une discussion et un choix collectif, sur des critères fonctionnels et de 
> pérénité de l’outil, pas sur des critères d’admin sys (parce que croyez moi 
> ou non, mais la maintenance de Redmine c’est quand même une sacré merde dans 
> son genre,  à moins peut-être d’être sur un serveur configuré spécifiquement 
> pour la pile Ruby On Rail)

Sur point je ne peut être que d'accord je continue à payer les pots
cassés de la maintenance de core.spip.net . D'autant plus que trac est
toujours là car on n'a pas réussi à la tuer.

> Là l’outil est imposé et manque de chance ça ne plait pas à grand monde, 
> d’autant plus qu’à côté on est beaucoup à être très contents de Gitlab 
> (libre) ou de Github (qui a l’avantage de ses défauts), qu’on utilise à côté 
> sur plein de projets
>
> Du coup personne n’a envie d’y aller, on traine des pieds, on louvoie, voire 
> on essaye d’esquiver en profitant du sujet N°2, à savoir Composer

Mais ça sera toujours le problème aucune solution ne plaira, il faut
trouver un équilibre/compromis

>
> 2/ Composer donc
> Qui impose de son côté des contraintes sur l’import Git, le découpage du core 
> et d’autres petits tracas techniques que James saurait mieux expliquer. Rien 
> d’insurmontable, mais aussi une migration vers Git un peu différente de ce 
> qu’avait préparé Camille du coup dans le découpage - mais je comprends que 
> dans les derniers travaux de Camille ça s’unifie.

Oui car les aspects dit techniques de composer ne sont pas des vrais
blocages, en tout cas sur les points que j'ai vu.
Comme par exemple versionner correctement un plugin sans casser tout
l'historique cela se fait.

Pour moi le problème principal reste les conventions dans le nommage
des différents projets (coté git , composer , )

> La publication des paquets et les mécanismes Packagist ne sont pas 
> compatibles avec Gitea, moyennement compatibles avec Gitlab, mais totalement 
> Github.
> Du coup il est tentant de dire : hop passons à Github, c’est facile pour ce 
> point Composer, et ça esquive Gitea sans trop en avoir l’air.

Composer est compatible avec n'importe quel vcs. C'est juste que si on
utilise github on peut se passer du vcs pour télécharger le zip en
direct. (les numéros de versions sont prédictibles)
Cela peut posera un problème dans le cadre d'une diffusion large.
Dans le cas actuel ce n'est pas le cas, on propose nous même le zip
unifié grand public cela n'est pas un point bloquant.
Et pour les développements si on est capable d'installer composer et
svn on est capable d'installer git.

> Mais voilà, on sent bien que c’est quand même une façon un peu moisie de 
> résoudre 1/ et du coup on tourne autour du pot.
>
> 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.

Ce qui pose problème c'est un tiers qui n'est pas de confiance (on en
a eu la preuve dernièrement) Il est pratique et monopolistique (et
pour moi assez éloigner de l'esprit communautaire de SPIP). Donc comme
point d'entrée et base de travail je coince beaucoup.

Cela n'empeche pas d'avoir une meilleure visibilité et une
simplification d'échange avec d'autres. Et pour rappel SPIP est déjà
sur github depuis des plombes. Le miroir est actif et fonctionnel.

> 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.

Toutefois le problème de 

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

2019-08-07 Par sujet Eric Lupinacci
Yo,


Le mer. 7 août 2019 à 09:34, Cerdic  a écrit :

> Hello,
> 1/ Gitea vs autre chose
> Il faut commencer par dire que Camille a fait un boulot énorme sur la
> migration a GIT, et l’en remercier.
> ...
> 2/ Composer donc
> Qui impose de son côté des contraintes sur l’import Git, le découpage du
> core et d’autres petits tracas techniques que James saurait mieux
> expliquer. Rien d’insurmontable, mais aussi une migration vers Git un peu
> différente de ce qu’avait préparé Camille du coup dans le découpage - mais
> je comprends que dans les derniers travaux de Camille ça s’unifie.
> 
> 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.
> ...
> Mais le point 1 reste à résoudre par une vraie discussion et un consensus,
> sinon on restera dans cette situation moisie où rien ne bouge.
>
>
Oui merci à Camille pour ce boulot énorme sur GIT et merci à toi Cédric
pour résumer la situation.
A la lecture de ton résumé résoudre le 1/ n'est pas une montagne
techniquement mais qu'il faut juste animer une vraie discussion qui
débouche enfin sur une décision.
Si je comprends bien aussi un choix autre que GitHub pourrait ne pas être
un frein au 2/ car on pourrait passer (au moins pendant un certain temps)
par un mirroring Github qui résoudrait les problématiques packagist.

Donc il faut choisir entre Gitea, Gitlab et Github, je suppose qu'il est
inutile d'envisager autre chose.
Peut-on faire faire une liste de critères à analyser pour alimenter la
discussion ?

- performances serveur
- facilité d'administration
- ergonomie de l'interface git
- gestion des tickets
- open-source + ou -
- API, langage source
- intégration d'outils externes
- ... ?

++
Eric

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


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

2019-08-07 Par sujet Cerdic
Hello,

il y a en effet deux sujets distincts mais avec une intersection non nulle ce 
qui pollue le débat.

Je vais donc mettre les pieds dans le plat et appeler un chat un chat.

1/ Gitea vs autre chose
Il faut commencer par dire que Camille a fait un boulot énorme sur la migration 
a GIT, et l’en remercier.

Mais le choix de Gitea est uniquement fait sur des critères techniques, pour 
faciliter l’admin sys, et non sur des critères d’utilisabilité ou de 
fonctionnalités (peut-être aussi pour des contraintes liés à la synchro 
svn-git, mais qui n’est plus à l’ordre du jour).

La dernière fois qu’on a changé d’outil (passé de Trac à Redmine), il y avait 
eu une discussion et un choix collectif, sur des critères fonctionnels et de 
pérénité de l’outil, pas sur des critères d’admin sys (parce que croyez moi ou 
non, mais la maintenance de Redmine c’est quand même une sacré merde dans son 
genre,  à moins peut-être d’être sur un serveur configuré spécifiquement pour 
la pile Ruby On Rail)

Là l’outil est imposé et manque de chance ça ne plait pas à grand monde, 
d’autant plus qu’à côté on est beaucoup à être très contents de Gitlab (libre) 
ou de Github (qui a l’avantage de ses défauts), qu’on utilise à côté sur plein 
de projets

Du coup personne n’a envie d’y aller, on traine des pieds, on louvoie, voire on 
essaye d’esquiver en profitant du sujet N°2, à savoir Composer

2/ Composer donc
Qui impose de son côté des contraintes sur l’import Git, le découpage du core 
et d’autres petits tracas techniques que James saurait mieux expliquer. Rien 
d’insurmontable, mais aussi une migration vers Git un peu différente de ce 
qu’avait préparé Camille du coup dans le découpage - mais je comprends que dans 
les derniers travaux de Camille ça s’unifie.

La publication des paquets et les mécanismes Packagist ne sont pas compatibles 
avec Gitea, moyennement compatibles avec Gitlab, mais totalement Github.
Du coup il est tentant de dire : hop passons à Github, c’est facile pour ce 
point Composer, et ça esquive Gitea sans trop en avoir l’air.

Mais voilà, on sent bien que c’est quand même une façon un peu moisie de 
résoudre 1/ et du coup on tourne autour du pot.

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.

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.


Mais le point 1 reste à résoudre par une vraie discussion et un consensus, 
sinon on restera dans cette situation moisie où rien ne bouge.

--
Cédric
Le 6 août 2019 à 16:02 +0200, cam.la...@azerttyu.net , 
a écrit :
> Salut
> > Cette discussion tombe à pic car j'avoue ne plus être sur de la fin de la 
> > saison précédente et je me demande si les producteurs ont décidé ou pas de 
> > renouveler la série "Git & Composer" pour une nouvelle saison.
> >
> > Si je résume (surement très approximativement) ce que je comprends de la 
> > situation :
> > - le "groupe de travail Composer" propose de passer SPIP (core + 
> > plugins-dist ?) sous Composer et donc pour faciliter l'administration (et 
> > patati patata) de migrer les sources sur la plateforme GitHub qui simplifie 
> > l'utilisation de Packagist. Le hic semble être GitHub pour certains même si 
> > on y a tous un compte...
> > - Camille a tout préparé pour que les sources de SPIP soit sous GIT avec la 
> > plateforme open-source Gitea qui n'est pas totalement compatible avec 
> > Packagist en l'état. Et Camille fait remarquer que si on migre sous GitHub 
> > on ne reviendra jamais sur Gitea, si dans le futur, Gitea devient 
> > "compatible Packagist" ou le contraire.
> >
> > Le problème c'est que personne n'a vraiment tort et donc résultat : on est 
> > bloqué comme cela nous est déjà arrivé et j'ai l'impression que cette idée 
> > de Composer est repoussée aux calendes grecques alors qu'elle est 
> > prometteuse et permettrait de sortir un peu de notre torpeur estivale.
> >
> > Aussi, a-t-on une porte de sortie rapide à cette situation ?
> > Je trouve la situation actuelle plus délétère qu'une potentielle "erreur" 
> > d'aiguillage.
> > Le choix GitHub est-il vraiment si terrible ?
> >
> >
> > Vos avis ?
>
> Comme depuis un moment les 2 trucs sont compatibles et n'ont pas grand
> chose à voir.
> Par exemple wordpress refuse composer et travaille avec svn et
> pourtant il existe une solution composer
>
> Parmi les freins identifiés (et que j'ai compris)
> * le problème des versions, dans le svn les tags sont relatifs à SPIP
> et non au plugin lui même
> * la possibilité de télécharger les zip (raison de github)
> * une nomenclature des organisations pour respecter la logique de
> nommage de composer.
> * le choix de la forge

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

2019-08-06 Par sujet cam.la...@azerttyu.net
Salut
> Cette discussion tombe à pic car j'avoue ne plus être sur de la fin de la 
> saison précédente et je me demande si les producteurs ont décidé ou pas de 
> renouveler la série "Git & Composer" pour une nouvelle saison.
>
> Si je résume (surement très approximativement) ce que je comprends de la 
> situation :
> - le "groupe de travail Composer" propose de passer SPIP (core + plugins-dist 
> ?) sous Composer et donc pour faciliter l'administration (et patati patata) 
> de migrer les sources sur la plateforme GitHub qui simplifie l'utilisation de 
> Packagist. Le hic semble être GitHub pour certains même si on y a tous un 
> compte...
> - Camille a tout préparé pour que les sources de SPIP soit sous GIT avec la 
> plateforme open-source Gitea qui n'est pas totalement compatible avec 
> Packagist en l'état. Et Camille fait remarquer que si on migre sous GitHub on 
> ne reviendra jamais sur Gitea, si dans le futur, Gitea devient "compatible 
> Packagist" ou le contraire.
>
> Le problème c'est que personne n'a vraiment tort et donc résultat : on est 
> bloqué comme cela nous est déjà arrivé et j'ai l'impression que cette idée de 
> Composer est repoussée aux calendes grecques alors qu'elle est prometteuse et 
> permettrait de sortir un peu de notre torpeur estivale.
>
> Aussi, a-t-on une porte de sortie rapide à cette situation ?
> Je trouve la situation actuelle plus délétère qu'une potentielle "erreur" 
> d'aiguillage.
> Le choix GitHub est-il vraiment si terrible ?
>
>
> Vos avis ?

Comme depuis un moment les 2 trucs sont compatibles et n'ont pas grand
chose à voir.
Par exemple wordpress refuse composer et travaille avec svn et
pourtant il existe une solution composer

Parmi les freins identifiés (et que j'ai compris)
* le problème des versions, dans le svn les tags sont relatifs à SPIP
et non au plugin lui même
* la possibilité de télécharger les zip (raison de github)
* une nomenclature des organisations pour respecter la logique de
nommage de composer.
* le choix de la forge
* la mise à disposition des paquets au format composer


Pour le premier point, cela est réglé via
https://git.spip.net/_outils_/creer_tags (il y a déjà un mail
spécifique pour expliquer son comportement)

Pour le second point, le plus simple serait de fournir un driver gitea
pour composer qui permettrait de choisir git ou zip.
 Ce point me semble mineur car si on utilise composer on a très
probablement la main sur la machine cible et donc la possibilité
d'installer aussi git
 L'api de gitea est proche de celle de de github, on peut donc
envisager de proposer le dit driver à composer pour supporter les
archives zip.
 Enfin il est toujours possible d'avoir github en miroir de gitea
(c'est déjà le cas pour la partie core de spip)

Pour le troisième point, il n'y a toujours pas eu de décision aux
diverses questions soulevées par mail. Cette non décision bloque la
pérennité de nommage dans les dépôts git ( peu importe la forge)
  Ce point me semble le plus problématique car il est uniquement organisationnel

Pour le quatrième point, je pense toujours que github est un mauvais
choix par défaut
  Ce mois ci une partie des contributeurs ont été bloqués juste pour
une histoire de politique américaine
  Ensuite il est tout à fait possible d'avoir github en miroir, c'est
déjà le cas
  git.spip.net fonctionne
  De mon coté j'aurais le même discours pour toute autre forge
propriétaire qui aurait pour vocation de gérer une communauté
complète. Il n'y a pas de transparence, pas de maîtrise, ...

Pour le cinquième point, packagist, satis simplifient énormément
l'écriture du fichier composer.json  (car ils fournissent les
correspondances de téléchargement/version/paquet).
  On peut s'en passer à condition d'écrire un fichier assez verbeux
(ce que j'ai testé et qui fonctionne)
  De ce que j'ai identifié il y a 2 morceaux importants
https://github.com/spipremix/composer-installer pour ranger les
différents projets git à leur place et le metapaquet pour piloter tout
ça


Actuellement il est possible d'utiliser composer (certes c'est un gros
fichier) d'autant plus qu'il est tout à fait possible d'améliorer
l'existant sans remettre en cause et tout casser car le futur c'est
mieux.
En tout cas de mon coté je travaille sur les différents points qui
seraient considérés comme bloquant.


Km

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


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

2019-08-06 Par sujet Eric Lupinacci
Hello,



Le lun. 5 août 2019 à 11:24, cam.la...@azerttyu.net 
a écrit :

>
> > 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é.
>

Cette discussion tombe à pic car j'avoue ne plus être sur de la fin de la
saison précédente et je me demande si les producteurs ont décidé ou pas de
renouveler la série "Git & Composer" pour une nouvelle saison.

Si je résume (surement très approximativement) ce que je comprends de la
situation :
- le "groupe de travail Composer" propose de passer SPIP (core +
plugins-dist ?) sous Composer et donc pour faciliter l'administration (et
patati patata) de migrer les sources sur la plateforme GitHub qui simplifie
l'utilisation de Packagist. Le hic semble être GitHub pour certains même si
on y a tous un compte...
- Camille a tout préparé pour que les sources de SPIP soit sous GIT avec la
plateforme open-source Gitea qui n'est pas totalement compatible avec
Packagist en l'état. Et Camille fait remarquer que si on migre sous GitHub
on ne reviendra jamais sur Gitea, si dans le futur, Gitea devient
"compatible Packagist" ou le contraire.

Le problème c'est que personne n'a vraiment tort et donc résultat : on est
bloqué comme cela nous est déjà arrivé et j'ai l'impression que cette idée
de Composer est repoussée aux calendes grecques alors qu'elle est
prometteuse et permettrait de sortir un peu de notre torpeur estivale.

Aussi, a-t-on une porte de sortie rapide à cette situation ?
Je trouve la situation actuelle plus délétère qu'une potentielle "erreur"
d'aiguillage.
Le choix GitHub est-il vraiment si terrible ?

Vos avis ?

++
Eric

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