Je fais suite à mon mail du 28/05 sur la bascule finale sous Git au 1 juillet.
Je rappelle que c’est toujours l’objectif.
Donc je relance un fil pour savoir si vous voyez des opérations préalables à faire dans les 15 jours.
Si c’est le cas il est temps de les identifier et de les faire.
Moi j’ai une question.
Si on découvre le 2 juillet que le plugin « smoutch » qui a été développé sous svn en 1515 pourrait être repris avec bonheur aujourd’hui sous git.
Est ce que le script de migration fonctionnera bien encore même sans subgit ?
Donc je relance un fil pour savoir si vous voyez des opérations préalables à faire dans les 15 jours.
Si c’est le cas il est temps de les identifier et de les faire.
L’autodoc des plugins n’est pas migré (je sais pas d’ailleurs pour spip).
Le fichier autodoc.txt est aussi lui toujours sous svn.
Comme "troll du lundi matin" (mais pas seulement), je dirais
- avoir un mode d'emploi garanti-vertifié
(car seule le debat sur l'inclusivité dépasse /peut-etre/ les multiples questionnements sur l'usage deGit
(décourageant toujours de s'y plonger
Pourtant je relis souvent les aides de Eric et JLuc....
Donc je relance un fil pour savoir si vous voyez des opérations préalables à faire dans les 15 jours.
Si c’est le cas il est temps de les identifier et de les faire.
C'est pas technique, mais tout aussi important, il faudra mettre à jour cette doc qui amha est la porte d'entrée pour les nouvelles personnes qui souhaitent contribuer :
De même, ce modèle de mail (interne) qu'on envoie lors de l'accueil est à mettre à jour et à migrer sur une autre site, git.spip.net me semble approprié :
Pour résumé, il faut qu'on revalide notre process d'accueil, car j'allais enfin prendre le temps de le faire pour Rémi (cf le fil à propos de html5up_lens) et je me rends compte que je ne sais plus quelle est la démarche maintenant qu'on est sous git, et surtout, je n'ai pas les droits pour lui créer un compte sur gitea...
Pour résumé, il faut qu'on revalide notre process d'accueil, car j'allais enfin prendre le temps de le faire pour Rémi (cf le fil à propos de html5up_lens) et je me rends compte que je ne sais plus quelle est la démarche maintenant qu'on est sous git, et surtout, je n'ai pas les droits pour lui créer un compte sur gitea...
Autre sujet aussi.
Sur la zone il nous reste encore les répertoires racine suivants qui ont été peu explorés:
- _acotes_ : dernière modification il y a 3 ans
- _composer_ : les tests de James
- _contribs_ : dernière modification il y a 5 ans
- _dev_ : on a récupérer Salvatore et univers_spip
- _doc_ : dernière modification il y a 7 ans
- _graphismes_ : dernière modification il y a 3 ans
- _modeles_ : dernière modification il y a 4 ans
Et _REGLES_DE_COMMIT et autodoc.txt
Je ne sais pas si il y a des choses récupérables d’emblée mais surtout on a _graphismes_ et _doc_ qui ne sont pas du tout du code et ne rentrent dans aucune organisation sous Gitea.
Ne faudrait-il pas créer un dernière organisation spip-contrib-annexes pour ce type de contributions graphiques ou autres ?
Et alors on y verserait quelques repos actuels à définir.
Pour _dev_ et _outils_ je renouvelle aussi ma proposition de faire une passe sur tous ces outils pour éventuellement faire des imports avant fin juin.
là comme ca je me dit que "doc" n'a rien a faire sur un gestionnaire de code (sauf si on décide à passer à de la doc embarquée), et que ca devrait être rappatrièe sur spip.net/contrib.spip.net
_modeles_ j0imagime qu'on a des modèles à part, mais ca mériterait s'ils sont utiles d'être encapsulés dans des plluginsd
Au premier juillet on peut bloquer le svn publiquement mais le laisser à disposition en interne.
Ainsi on conserve les possibilité d'import/migration comme maintenant même après la date fatidique.
Je fais suite à mon mail du 28/05 sur la bascule finale sous Git au 1 juillet.
Je rappelle que c’est toujours l’objectif.
Donc je relance un fil pour savoir si vous voyez des opérations préalables à faire dans les 15 jours.
Si c’est le cas il est temps de les identifier et de les faire.
La finalisation de la doc me parait importante aussi pour que celles et ceux qui n'ont pas encore migré ou qui sont en cours puissent suivre. Sinon, on risque d'avoir bcp de retours à partir du 2 juillet
l’idée c’est *aussi* de se débarrasser de la complexité de subgit, de tout simplifier côté serveur en espérant que ça nous permettra d’arriver à une plateforme plus stable et robuste, parce que là pour le moment on peut pas dire qu’on soit super heureux...
Donc je pense qu’on va couper définitivement et complètement svn - ou à la rigueur il pourrait rester accessible en lecture depuis le serveur pour faire des git svn clone et migrer en git avec l’historique si on veut, du moment que toute la passerelle svn-git soit définitivement coupée et qu’on s’embête plus avec ça.
Mais franchement, on a récupéré tout l’important, si les trucs qu’on a oublié sont migrés sans historique dans le futur on en mourra pas. Il y a un moment il faut faire des choix adaptés à nos ressources.
On ne veut justement pas tous les dépôts maintenu par l'équipe noyau. Tous ne sont pas dans les plugins-dist distribués de base. Pour chaque distribution, les plugins-dist sont une liste explicite, qui n'est ni l'entièreté des dépôts de l'orga "spip", ni n'est forcément la même pour chaque version de SPIP.
Je m'interroge toujours là dessus : est ce qu'on le remplace par une simple liste en json par exemple, versionnée par branche donc, en attendant d'avoir une vraie gestion de dépendances ?
Car s'il est sur la communauté désormais, dans le fichier c'est toujours celui de Github qui est déclaré + c'est juste stocké dans le master + ensuite dans checkout/spip-cli yavait une bidouille d'exception *en dur* dans le code, disant que ce plugin en particulier ne devait être mis que pour le master et pas les autres. Et donc là à priori faut tout changer de comment ça fonctionne, et oui il faudrait une liste explicite pour chaque branche.
Avec quelques regex sur plugins j’ai identifié des plugins compatibles spip 3 mais non migrés.
Il y a en environ 150.
La liste est ici : http://spip.pastebin.fr/63331
J’ai mis un commentaire sur certains qui me paraissent obsolètes.
Pour le reste il faut décider mais au moins on a une liste.
je veux bien migrer apropos sous git, mais j’ai envoyé un message il y’a quelques semaines pour connaitre la méthode, mais sans réponse. Comment faire pour migrer mon plugin compte tenu de ma maigre connaissance de tous ces environnements ?
Le problème de Apropos c’est que la structure SVN est n’importe quoi.
Il existe un dossier Alpha/ : c’est quoi ?
un dossier branches/ avec des sous-dossiers spip2/ et spip3/ (qu’il faudrait renommer en v0 et v1) et sous spip3/ on retrouve un dossier apropos_3/ qui ne devrait pas y être
un dossier trunk/ qui semble ok.
Donc qu’est ce qui est à jour ?
Est-il besoin de récupérer tout ou peut-on admettre de perdre des commits ?
