Pour la partie synchro git/svn le projet subgit a bien avancé et me
semble plus mur pour passer en prod.
Mais parmi les points à traiter, il y a :
-* migrer le svn core sur celui de la zone (afin d'avoir une meilleure maitrise)
-* avoir le bon script de synchro entre le nouveau serveur et l'ancien
pour faciliter la transition
-* remettre d'aplomb l'arborescence pour etre sur que c'est sain
-* faire sauter les svn:external qui sont le mal de svn
-* trouver un ensemble de script correctifs pour obtenir la plugins de
la distrib
-** le distribution.xml discuté un temps
-* fournir un script svn de checkout qui recupere core et plugins distrib
-* mettre à jour spip loader pour faire de même
-* finaliser gitolite pour lister les droits des core dev et permettre
la gestion des intégrations des patches extérieurs
Chez mois ça tourne en prod sans problème, tous mes devs sont
maintenant git/svn. Ce qui a permis de regler pas mal de petits
problèmes fonctionnels
Là je suis en train de tester chez alternc car chez eux le svn est
plus simple et un peu mieux structuré, si rien ne pete je pense qu'on
pourra dire que ça le fera pour spip aussi.
avant de bouger quoi que ce soit, il faut en effet résoudre le problème des externals,
ce qui passe grosso modo
- par un fichier de description des plugins-dist (formalisme à definir)
- un mécanisme de téléchargement/checkout (attentions aux scripts sh qui ne sont pas utilisables sous windows)
- la mise à jour des procédures et scripts de release
Pour réorganiser les plugins du core sur la zone (en les déplaçants tous dans _plugins_/ comme les autres, avec un trunk/branches/tags), il faut aussi :
- mettre en place un outil pour faire les reports en nombre entre branche dev (trunk) et branche stable des plugins-dist
- modifier les scripts de release
2/ GitHub
Cela dit, et une fois cela fait, je me demande sincèrement si on ne se simplifierait pas la vie à passer le core sur GitHub plutôt que continuer à maintenir nous même un service et des outils plus ou moins (in)satisfaisants :
- GitHub gère maintenant la contribution en Subversion, ce qui permet une transition douce, à ceux qui le veulent de continuer à utiliser SVN (avec ses inconvénients&limites, mais aussi son avantage de simplicité)
- La gestion des issues dans GitHub est très bien faite et pratique
- La plateforme augmente clairement la visibilité du projet, et la facilité à forker, proposer des patchs, des pulls...
- GitHub est une plateforme de plus en plus connue et utilisée : utiliser les mêmes outils que tout le monde ne peut être que bénéfique pour les contributeurs qui ne seront en terrain connus (on a un mal fou à faire poser un ticket, même par des devs utilisateurs de SPIP parce que ça les force à créer un compte, utiliser RedMine etc. alors qu'ils ont souvent déjà un compte GitHub et ont déjà déposé un ticket chez GitHub)
- L'utilisation de SVN sur Mac (hors ligne de commande) est assez peu pratique, alors qu'il y a une application GitHub pour Mac très conviviale et simple d'utilisation.
GitHub a l'inconvénient du service centralisé, mais en utilisant Git qui ne l'est pas, on garde notre liberté puisqu'on a chez chacun une version complète du repository qui peut être réinstallé n'importe où.
Je pense que cela vaut le coup de se poser la question.
Cela dit, et une fois cela fait, je me demande sincèrement si on ne se simplifierait pas la vie à passer le core sur GitHub plutôt que continuer à maintenir nous même un service et des outils plus ou moins (in)satisfaisants :
- GitHub gère maintenant la contribution en Subversion, ce qui permet une transition douce, à ceux qui le veulent de continuer à utiliser SVN (avec ses inconvénients&limites, mais aussi son avantage de simplicité)
- La gestion des issues dans GitHub est très bien faite et pratique
- La plateforme augmente clairement la visibilité du projet, et la facilité à forker, proposer des patchs, des pulls...
- GitHub est une plateforme de plus en plus connue et utilisée : utiliser les mêmes outils que tout le monde ne peut être que bénéfique pour les contributeurs qui ne seront en terrain connus (on a un mal fou à faire poser un ticket, même par des devs utilisateurs de SPIP parce que ça les force à créer un compte, utiliser RedMine etc. alors qu'ils ont souvent déjà un compte GitHub et ont déjà déposé un ticket chez GitHub)
- L'utilisation de SVN sur Mac (hors ligne de commande) est assez peu pratique, alors qu'il y a une application GitHub pour Mac très conviviale et simple d'utilisation.
Sur ce dernier point l'inverse est aussi vrai sous linux : il y a des outils graphiques pratiques et jolis pour SVN mais pas vraiment pour GIT ou Github.
GitHub a l'inconvénient du service centralisé, mais en utilisant Git qui ne l'est pas, on garde notre liberté puisqu'on a chez chacun une version complète du repository qui peut être réinstallé n'importe où.
Oui, à l'exception des tickets peut-être ?
Je pense que cela vaut le coup de se poser la question.
GitHub a l'inconvénient du service centralisé, mais en utilisant Git
qui ne l'est pas, on garde notre liberté puisqu'on a chez chacun une
version complète du repository qui peut être réinstallé n'importe où.
Oui, à l'exception des tickets peut-être ?
Pour info, je viens de trouver ce projet qui permet de faire un backup presque complet d'un repo github :
github-backup is a simple tool you run in a git repository you cloned from GitHub. It backs up everything GitHub publishes about the repository, including branches, tags, other forks, issues, comments, wikis, milestones, pull requests, and watchers.
Reste à voir comment on peut réutiliser les données des issues ensuite...
Rah j'avais répondu ce matin, mais à cause du load Gmane, ça n'a rien envoyé en fait.
Hello,
Deux points :
1/ Les outils de gestion des externals
avant de bouger quoi que ce soit, il faut en effet résoudre le problème des externals,
ce qui passe grosso modo
- par un fichier de description des plugins-dist (formalisme à definir)
Oui... oui... on est en retard.
Ya un début de proposition, mais il faut l'améliorer pour être sûr de gérer la majorité des cas possibles.
- un mécanisme de téléchargement/checkout (attentions aux scripts sh qui ne sont pas utilisables sous windows)
Pour les développeurs oui. Il faut un mécanisme pour reproduire le "svn up" actuel à la racine, qui permet de mettre l'ensemble de la distribution à jour (core + ce qui a été décidé de mettre dans plugins-dist).
Pour les utilisateurs plus classiques, c'est à smart-paquets ou assimilé de savoir produire un paquet ZIP complet, téléchargeable d'un coup, donc là peu importe le langage.
2/ GitHub
Je pense que cela vaut le coup de se poser la question.
Utiliser des outils déjà en place et qui apparemment fonctionnent ne gêne pas si :
- on est sûr de pouvoir partir quand on veut (on aura chacun le dépôt Git, mais quid des tickets ?)
- on a confiance dans l'intermédiaire pour gérer la confidentialité des utilisateurs (pour l'instant, les contributeurs de SPIP font confiance aux mainteneurs des outils de la communauté, mais si on utilise un outil externe alors on délègue cette confiance).
Si ces deux points sont bons, je ne vois pas de problèmes pour utiliser Github ou autre service en ligne.
Permettez-moi de faire une remarque en cette occasion. Utilisateur de longue date de spip et redistribuant régulièrement le logiciel auprès de structures principalement non-commerciales, je regrette très souvent que les utilisateurs de logiciels libres et particulièrement de celui-ci n'aient de cesse d'assimiler "libre" à "gratuit".
Jusqu'ici jamais (à moins que je me trompe, ce qui est possible) je n'ai lu d'appel à contributions émanant du projet SPIP. À mon avis il se justifierait ne serait-ce qu'à titre "pédagogique", pour rappeler dans ce contexte que le développement même bénévole correspond à des coûts, notamment si par exemple les développeurs de spip préféraient disposer d'un serveur git complètement autonome, ménageant ainsi leur indépendance...
Autre remarque du même ordre : un bouton "soutenez spip" sur spip.net pointant sur les moyens de soutenir financièrement le projet, serait a minima une façon de signifier que le soutien au logiciel passe aussi par d'autre canaux que par sa simple utilisation...
Je pense que cela vaut le coup de se poser la question.
Et une fois qu’on est sous Github on travaille tous dans notre coin ?
J’ai un peu de mal suivre deux threads aussi qui se recoupent sur deux listes différentes.
Ce que je vois de positif de passer par Github, c’est de s’appuyer (et bénéficier) d’un hébergement nickel sans effort d’investissement de ceux qui gèrent les différents services de la communauté (pensez à nos vacances, maladies, fêtes entre potos, etc…). On a entendu assez souvent « la zone, ça rame », pour savoir qu’un tel service de qualité c’est important.
Donc (en tant que co-hébergeur de la zone et à titre perso) je vote pour.
Je pense que cette décision ne peut être prise que quand nos processus de collaboration sont clairs et agréés entre nous et que c’est bien Github qui peut le mieux les supporter. Sinon on met l’outil avant les boeufs… mais ça serait pas la première fois.
Oui, je suis d’accord : la continuité dans l’utilisation de nos outils (svn ou git) est importante.
Comme le soulignait Cedric dans un autre mail, il est aussi important que notre mécanisme de sortie de release soit adapté à ce nouvel hébergeur.
Pour ma part, je pense que c'est effectivement un bonne idée de passer par un service tier (github ou autre) si cela permet de soulager les gestionnaire de la zone/du core, et à condition qu'on puisse récuperer toutes les données (et pas seulement le code).
Concernant l'interface git svn, j'imagine qu'on peut faire un svn switch pour brancher d'un tags à l'autre ?
perso je ne travaille jamais sur aucune branche, par contre j'utilise regulière svn switch pour changer de tags c'est svt plus rapide que le loader...
Vouloir confier les données de sa vie non professionnelle (i.e. totalement privée ou loisirs notoires comme l'est le développement de SPIP) à un site centralisé sur lequel on a aucune prise est depuis quelques années une tendance lourde qui pour ma part m'inspire la plus grande méfiance par principe. Aujourd'hui il semble que les propriétaries de Github ne peuvent pas faire de mal avec les données qu'ils hébergent, mais on sait ce qu'il est advenu des outils apparement sans conséquences proposés par Google et autres Facebook.
A ce principe de précaution, j'ajoute l'argument d'Eric que j'amplifie. On a trop souvent eu tendance dans l'équipe à adopter un nouvel outil en pensant que ça allait aider à résoudre un problème organisationnel, ça n'a jamais marché et ce n'est pas surprenant. Qu'aujourd'hui pour passer à Git on soit gêné par les Externals de Svn est assez révélateur: leur recours n'a pas réglé le problème organisationnel mais on a rajouté un problème technique, quel bilan ! D'une manière générale, je pense que le développement de SPIP souffre de ne savoir jamais dire non à la nouveauté pour la nouveauté et au changement pour le changement.
Qu'on apprenne déjà à utiliser les branches de Subversion, qui ne sont pas quand même pas tellement moins efficaces que celles de Git, et on verra si vraiment on tombe sur des difficultés strictement liées aux insuffisances déclarées de Subversion. Perso, j'en doute fort.
