Il y a beaucoup de traitements via l’API Gitlab au moment de l’import, et du coup oui ça prend la date de mise à jour à cet instant dans Gitlab, ce qui classe les projets… à peu près dans l’ordre alphabétique de traitement… Je ne crois pas qu’on ait de solution à cela lors de l’import.
Un compte inutilisé n’a pas d’effet sur la forge actuelle.
Dans gitea, c’est assez simple à identifier car ce sont des des comptes qui n’ont a été connecté depuis leur création.
Ensuite la gestion actuelle c’est de traiter les boucnces (retour d’erreur email) à la main.
Si un compte mail retourne des erreurs, je vérifie si le compte a été utilisé ou non depuis sa création. Sinon il est désactivé, si oui je contacte la personne en direct. La majeure partie du temps c’est le premier cas.
Oui mais ça permet de faire un peu de ménage sur les comptes surtout que les mots de passe vont changer.
Je pense qu’il vaut mieux garder uniquement des comptes actifs, enfin à mon avis.
Ben ça dépend de quand on souhaite migrer. On a une date ?
Si. tu vas dans le dashboard de Contrib tu vois qu’il n’y a pas des inscriptions tous les jours.
Et si on peut tout faire par Gitlab sans perdre la capacité de filtrer les comptes fake ça le fait aussi et ça évite de maintenir une autre alternative avec du code. Le dashboard de Contrib montre qu’il y a une inscription sur deux qui est une fausse inscription.
Ah oui, c’est juste, il y a la recherche de code sur chaque projet par défaut déjà tout de même.
On regardera pour activer la recherche avancée qui permettrait de chercher du code sur l’ensemble de la forge.
Bah non, quand tu cherche une fonctionnalité tu n’as pas forcément en tête le nom du plugin associé.
C’est même une des raisons de la page actuelle de la forge qui propose une recherche globale par défaut.
Donc vous avez souscrit à l’offre payante ? Vu que cette fonctionnalité n’est pas, à ma connaissance, native à la version communautaire.
@azerttyu la discussion on l’a eu il y a 5 ans [spip-dev] Mise à jour git.spip.net - #13 par eric_tonton
En résumé quand il s’est agit de choisir entre gitlab et gitea tu nous as dit : « gitea c’est plus maintenable, c’est plus rapide, c’est mieux foutu techniquement et moi je veux pas héberger de gitlab omnibus et personne d’autre se propose »
Dont acte, on a fait de notre mieux avec gitea, on a sincèrement essayé de faire tout bien marcher. Mais quelles que soient les features que proposent gitea, la première feature d’une forge c’est de versionner de manière fiable du code. Hors on a eu des soucis en 2020 déjà, gitea nous rembobinait le repo après push [spip-dev] Soyez sympa, arrêtez de rembobiner.... A l’epoque on a mis ça sur le dos de subgit qu’on a enlevé partout.
Je sais pas si c’est toujours un héritage malheureux de subgit, un problème de gitea, ou autre, mais le fait est qu’on en est toujours à se demander quand on va perdre des commits ou pas. C’est juste pas possible, on a autre chose à faire que surveiller la forge pour savoir si elle versionne bien ce qu’on lui envoie… Peut-être que de ton point de vue on réagit fort pour « 1 mois de problèmes », mais tu ne de rends pas bien compte de tous les efforts qu’on fait depuis longtemps pour « faire avec gitea ».
Par ailleurs, en 5 ans de notre côté on a eu l’occasion d’expérimenter l’hébergement de 2 forges gitlab et franchement on a eu aucun soucis depuis tout ce temps, y compris avec l’une des forges qui tourne avec des CI, est utilisé intensivement par des plusieurs dizaines de dev au quotidien etc.
Donc voilà, du coup on se dévoue pour héberger un gitlab pour spip, ça nous sort de l’impasse gitea. Et peut-être qu’on va perdre la recherche de code générale en effet, je n’avais pas vu ça, je l’avais jamais utilisée dans gitea. Mais pour tout le reste je crois qu’on y gagne largement, y compris en rapidité de la forge même si ruby vs go etc. La boussolle n’est pas un soucis comme tu peux le voir sur le proto de migration, et désormais Gitlab est aussi traduit correctement en français.
Y a rien de grave ni de personnel, c’est la vie. Quand on a trouvé que redmine était mieux que trac on a basculé de trac à redmine. Gitea fait des trucs bien, mais en utilisation intensive il offre décidément pas la robustesse et la fiabilité d’un gitlab, et maintenant qu’on a vraiment essayé on en est certain.
Et avec le recul de 5 ans, Gitlab s’impose aussi comme l’écosystème alternatif à github et il me semble pas qu’on puisse douter du support ou des ressources disponibles pour la maintenance du projet, quand au contraire Gitea doit absorber les conséquences d’un fork.
Bref je vois pas trop quelle raison on aurait de rester sur gitea dans ces conditions… ?
Bonjour
Comme je l’ai déjà dit, votre façon d’agir est particulièrement violente. Sur cet échange j’ai essayé de faire la part des choses et d’être constructif et de ne pas surréagir. Là malheureusement cela ne va plus être possible. Je suis humain et cela me rassures.
@cerdic tu sors enfin du bois. Je me demandais combien de temps @marcimat allait encore venir la fleur au fusil.
Vous m’informez le fait accompli, alors que j’ai pris le temps de vous contacter personnellement courant janvier pour essayer de travailler ensemble sur la situation. C’est juste violent et déplacé.
Vous faites semblant de demander à la communauté leur avis. Vous continuez sans vous en préoccupez c’est votre choix.
Oui comme l’autre fois où un contributeur avait mal configuré son logiciel. Tu ne t’es pas privé avec tes aimables commentaires pleine d’analyse, c’est facile de taper sans réfléchir.
Sur la douzaine d’années écoulée, je n’ai clairement pas à rougir de la stabilité de l’ensemble. Comme à chaque fois chaque incident m’a posé problème tant personnel que technique. J’ai toujours essayé de trouver une solution. Même quand cela me dépassait malgré moi.
Tiens là tu oublies tout le travail qui a été nécessaire pour vous convaincre à passer de trac à redmine. On était très loin d’une telle évidence.
Tu oublies également ton absence de participation sur les plus de 5 ans qui ont été nécessaires à migrer depuis SVN vers git.
Et venir m’informer en off que je n’implique pas dans la communauté alors que j’ai assuré sur plus de douze ans le service, je trouve ça malhonnête.
Tiens on redécouvre ces questions sur les droits à la contribution. Il y a une logique par rapport aux possibilités par défaut des contributeur ou du suivi à la vie du code de la communauté qui me semble faire partie de l’adn et de l’histoire même du projet. Je me demande bien comment cela va être disparaître prochainement.
Quel dévouement, contrairement à vous je ne suis pas un pro2spip, je n’ai aucun intérêt personnel ou professionnel à l’écosystème. Alors oui j’ai continué à m’impliquer à mon niveau et mes disponibilités.
Juste avec de l’affect à un souvenir d’un état d’esprit. Alors lire ceci me me fait clairement gerber.
Vous expliquez dans le fil que vous avez rencontré des problème avec vos scripts de migration. Il sont où sur la forge ? Elles sont où vos demandes d’échange pour que cela se passe au mieux et déboguer ce qui est possible ?
Le genre de remarque qui fait que SPIP n’existerai même plus maintenant …
Je réagis à votre demande d’expérimentation et je vous faits des retours factuels et tu te permets cette tirade. Cela ma fait sourire … jaune.
Si transformer un projet communautaire en projet d’éditeur n’est pas bloquant, rien ne s’y oppose.
Si les régressions identifiées n’en sont pas, rien ne bloque.
Si ce fil de discussion n’était pas un demande, ce n’est pas bloquant non plus.
Et probablement en plus de ces points du hors sujet, car il y a toujours du personnel, de l’affect et autres aspects humains dans nos choix et réactions.
Je pense que votre décision est mauvaise pour la communauté car vous centralisez l’écosystème, que vous basculez sur des solutions fermées, que la solution proposée apporte des régressions collaboratives et que vous manquez de transparence.
Enfin, Je n’ai rien fait et ne ferais rien pour bloquer une telle évolution et j’aiderai dans la mesure de mes moyens même si je la pense mauvaise pour votre futur.
1 « J'aime »
Camille,
Je comprends tout à fait ta frustration après des années surtout que j’y ai passé aussi des heures carrées lors de la migration SVN vers GIT.
Maintenant, on ne peut pas dire que cette discussion autour de Gitea vs Gitlab ou autre soit nouvelle.
On a d’ailleurs tous suivi ta proposition à l’époque pour voir si celle-ci était viable sur le long terme.
Aujourd’hui les utilisateurs les plus aguerris dont je ne fais pas partie semblent embêtés par l’utilisation de Gitea.
Il faut en tenir compte car notre but n’est pas Gitea mais SPIP et nous avons largement testé la solution Gitea : ce n’est pas un coup de tête.
Tout ce qui nous facilite l’évolution de SPIP est bon à prendre dans la mesure où cela respecte nos principes communs.
Là où je ne peux pas te suivre c’est sur les « accusations » envers @cerdic et @marcimat.
Je ne pense pas qu’il y ait de la malveillance dans leurs propos ou dans leurs actes mais uniquement des propositions pour laisser ce sujet derrière nous une fois pour toute.
Nous n’avons pas les moyens de combattre sur plusieurs fronts structurants à la fois.
Laissons rapidement ce sujet derrière nous et allons de l’avant sur SPIP car je trouve que les discussions sur son développement fonctionnel s’appauvrissent au profit d’évolutions purement technologiques.
3 « J'aime »
Mais du coup il y a d’autres régressions ? Ça fait 2 fois que tu utilises le pluriel, mais tu n’a parlé que de la recherche dans toute la base de code. Tu as vu d’autres fonctionnalités perdues ?
Bonjour
A priori tu n’es pas l’unique membre de la communauté ? Et on supposait déjà ton désaccord, historique sur ce sujet de Gitlab. L’avis d’autres personnes est aussi apprécié.
Tu parles de la phrase «Tu sembles aussi moins présent dans la communauté ces derniers temps» ? sérieusement ? Et tu traduis par «pas» depuis 12 ans ?
Tu avais signalé que tu ne lisais plus IRC ou Discuter et qu’il fallait alors t’envoyer un mail lorsqu’un problème survenait sur la forge, ce dont @b_b se chargeait la plupart du temps…
Par ailleurs, elle est où la communauté lorsqu’on s’occupe des releases de SPIP @b_b, moi et quelques autres, et essentiellement sur notre temps libre aussi ?
Pour la centralisation, bah oui de facto, on gère et maintient déjà plusieurs sites communautaires de SPIP et différents outils liés… est-ce réellement dramatique ?
Pour le reste,
- Gitlab n’est pas fermé, et ça reste du Git
- Il y a peu de régression en passant sur Gitlab, et au contraire de nombreux points d’UI bien pratiques dedans
- C’est quoi manquer de transparence alors que nous discutons ici ?
1 « J'aime »
Bonjour
Je pense avoir dire ce que je pensais de la situation. Il ne me semble pas utile d’ergoter plus sur le sujet. C’est acté.
C’est comme dirait certain c’est la vie.
Merci de me tenir informé de la bascule et des autres services à migrer.
C’est un peu délicat d’intervenir « de l’extérieur », quelques mots sur la forme tout de même.
Tout en étant évidemment reconnaissant à toutes celleux qui prennent sur leur temps pour faire tourner la machine et trouver des solutions, j’espère que l’on ne va pas perdre la contribution et l’expertise de Camille à l’occasion de cette bascule.
Des raisons pragmatiques on été évoquées pour motiver le changement, mais on devine en sous-texte qu’une part d’agacement ait pu précipiter la décision, suite aux problèmes récemment rencontrés sur la forge.
Je veux dire par là que ça a peut-être coupé court aux discussion en quelque sorte, sans chercher à garder Camille dans la boucle et obtenir son aval, et on peut comprendre son ressenti.
Je ne sais pas si c’est ce qui s’est passé, mais c’est l’impression que ça donne.
Un retour sur une possibe régression : je remaque que les pages « activité » n’ont plus de contribution.
Exemple sur mon compte : tcharlss · GitLab
Ou sur celui de matthieu : marcimat · GitLab
Est-ce symptomatique de quelque chose de perdu lors de la migration ?
gitea :
gitlab :
1 « J'aime »
Ah yep, là pour sûr ça va être compliqué !
1 « J'aime »
Tu parles de cette recherche là Explore - SPIP on GIT ? On est bien d’accord, ça n’est pas la même chose qu’une recherche globale dans le code ? De ce que j’en vois de l’utilisation que j’ai du gitlab hébergé par framasoft, la recherche permet de taper dans les repos comme c’est le cas actuellement dans gitea.
À moins que Frama ait souscrit à une offre payante, ce qui m’étonnerait, c’est bien possible dans le périmètre d’un groupe, ce qui est déjà bien suffisant je trouve.
Merci mignon 
Premier retour après un survol rapide et migraineux en étant grippal… J’ai l’impression qu’on a perdu les images jointes aux commentaires Intégrer le faux champ de recherche JS dans la carte de la saisie (!72) · Requêtes de fusion · spip-contrib-extensions / gis · GitLab & Intégrer le faux champ de recherche JS dans la carte de la saisie (!72) · Requêtes de fusion · spip-contrib-extensions / gis · GitLab
J’ai l’impression aussi : Correctif inversion hauteur - largeur (!18) · Requêtes de fusion · spip-contrib-extensions / image_responsive · GitLab
vs #18 - Correctif inversion hauteur - largeur - image_responsive - SPIP on GIT
Ah oui, zut… certaines sont passées tel que sur Réafficher où on se trouve sur la page de login (!5764) · Requêtes de fusion · spip / spip · GitLab ;