[spip-dev] [spip dev] clone core sur la zone ?

Dev
1

Bonjour,
Partant de mes suppositions suivantes :

  • il est parfois décourageant pour les membres de la zone de trouver l’origine d’un bug et de proposer un patch via les différents moyens mis à disposition, et que du coup on signale juste le bug (la flegme de chercher lorsqu’on peut pas proposer, pardon si je suis le seul à qui ça fait ça),
  • dans certains cas, proposer un patch ou un ajout via la liste ou redmine, ça ne facilite pas vraiment la lisibilité de ce dernier pour l’équipe du core (euh, c’est une supposition, je souligne bien)

ne pourrait-on pas disposer d’un clone du core sur la zone, avec le fonctionnement suivant :

  • Un commit sur le core est automatiquement reporté sur le clone
  • Le clone est ouvert à tous les membres de la zone
  • Le report d’une modif du clone sur le core est facilitée, une simple validation par un membre du core suffit
    J’ai eu cette idée en me disant que ça allégerait le boulot pour l’équipe pour des petites corrections ou ajout simple et motiverait peut être (plus) les membres de la zone à s’investir dedans. Ou pas ?
2

Ce type de fonctionnement sur un repo SVN serait très lourd à gérer, car les reports svn à svn entre 2 repositories sont assez pénibles à faire, il n’y a pas réellement d’outil pour ça.

Ce que tu décris est typiquement un mode de fonctionnement très adapté à GIT, qui permettrait à chacun de forker et proposer des patchs depuis sa version locale.
Mais force est de constater qu’on a un peu de mal sur le passage SVN->GIT, essentiellement pour des raisons de prise en main de l’outil GIT que l’on fait par analogie avec SVN, ce qui conduit à un mauvais usage de GIT et l’impression que ça nous freine/complique la vie.

Ta demande est cependant très juste, et c’est aussi une façon de nous mettre un coup de pied aux fesses pour que l’on ne s’endorme pas dans notre confort relatif, et qu’on fasse l’effort manquant pour passer sur ce mode de fonctionnement.

Il faut qu’on passe par la case « GIT c’est facile » pour pouvoir basculer et que la communauté dans son ensemble en tire profit, même si nous on a un peu l’impression de ramer au début.

Cédric

3

Comme le dit Cédric, ce genre de scénario est grandement facilité par
Git, qui est exactement fait pour ça.

   - Un commit sur le core est automatiquement reporté sur le clone

Par chance, c'est déjà le cas : on utilise Git à moitié, en
synchronisant en temps réel un dépôt Git à partir du dépôt SVN.

Pour l'utiliser, il suffit de cloner le dépôt suivant (je ne détaille
pas ici, il y a plein de doc sur le net) : http://git.spip.org/spip.git

   - Le report d'une modif du clone sur le core est facilitée, une
simple validation par un membre du core suffit

Il te suffit de demander une intégration dans le core en indiquant
l'URL où ton clone modifié est accessible. Pour faciliter les choses,
je te conseille de créer une branche quand tu démarres une nouvelle
correction/fonctionnalité.

On ne pourra pas encore intégrer ton patch en utilisant un merge natif
de Git, mais on l'intègrera de toute façon (en SVN, et donc ta modif
sera à son tour envoyée dans Git automatiquement). Dans tous les cas,
pour toi ça revient au même.

   - Le clone est ouvert à tous les membres de la zone

Le dépôt indiqué plus haut ne reçoit que les commits des core-devs, car
c'est la version "officielle". Cependant, tu peux tout-à-fait créer
un clone de ce dépôt, que tu ouvres à qui tu veux, pour faciliter les
choses encore un peu plus pour les gens.

Ce clone peut être sur ton serveur perso, ou sur un outil comme Github
par exemple, qui fournit tout un tas d'outils clic-clic pratiques.
D'ailleurs je synchronise régulièrement le dépôt officiel vers
celui-ci :

https://github.com/spip/spip

Je le fais manuellement quand j'y pense, mais toute aide est la
bienvenue si cette option intéresse des gens.

4

2011/2/23 davux <da@weeno.net>

Comme le dit Cédric, ce genre de scénario est grandement facilité par
Git, qui est exactement fait pour ça.

  • Un commit sur le core est automatiquement reporté sur le clone

Par chance, c’est déjà le cas : on utilise Git à moitié, en
synchronisant en temps réel un dépôt Git à partir du dépôt SVN.

Pour l’utiliser, il suffit de cloner le dépôt suivant (je ne détaille
pas ici, il y a plein de doc sur le net) : http://git.spip.org/spip.git

  • Le report d’une modif du clone sur le core est facilitée, une

simple validation par un membre du core suffit

Il te suffit de demander une intégration dans le core en indiquant
l’URL où ton clone modifié est accessible. Pour faciliter les choses,
je te conseille de créer une branche quand tu démarres une nouvelle
correction/fonctionnalité.

On ne pourra pas encore intégrer ton patch en utilisant un merge natif
de Git, mais on l’intègrera de toute façon (en SVN, et donc ta modif
sera à son tour envoyée dans Git automatiquement). Dans tous les cas,
pour toi ça revient au même.

  • Le clone est ouvert à tous les membres de la zone

Le dépôt indiqué plus haut ne reçoit que les commits des core-devs, car
c’est la version « officielle ». Cependant, tu peux tout-à-fait créer
un clone de ce dépôt, que tu ouvres à qui tu veux, pour faciliter les
choses encore un peu plus pour les gens.

Ce clone peut être sur ton serveur perso, ou sur un outil comme Github
par exemple, qui fournit tout un tas d’outils clic-clic pratiques.
D’ailleurs je synchronise régulièrement le dépôt officiel vers
celui-ci :

https://github.com/spip/spip

Je le fais manuellement quand j’y pense, mais toute aide est la
bienvenue si cette option intéresse des gens.

–
davux

Merci pour vos éclaircissements !
Si je comprends bien, par exemple : je clone la version actuelle sur Github dans un nouveau projet « spip_prop » (par exemple), j’y apporte des correction et je fournis l’url à spip-dev pour proposer, ces modifs sont probablement retouchées, parfois intégrées (ou pas) dans le core.
Je veux revenir à la version officielle sur « spip_prop » après cette étape, je ne dois pas tout réimporter ? Y a moyen qu’il compare les 2 projets et n’écrase que les différences ? Parce que dans ce cas, un git merge ne va t-il pas détecter des conflits ? (alors que je m’en fous à ce moment, je veux qu’il écrase ma version modifiée par la version modifiée du core pour repartir sur la « base saine »).

Bon, le mieux, c’est peut être que j’essaye de m’y m’être et de voir ce que ça donne !

5

23/02/11, Guy:

Merci pour vos éclaircissements !
Si je comprends bien, par exemple : je clone la version actuelle sur
Github dans un nouveau projet "spip_prop" (par exemple),

Oui. Dans le cas de Github, avec leur vocabulaire, tu clones spip/spip
en guy/spip.

j'y apporte
des correction et je fournis l'url à spip-dev pour proposer, ces
modifs sont probablement retouchées, parfois intégrées (ou pas) dans
le core. Je veux revenir à la version officielle sur "spip_prop"
après cette étape, je ne dois pas tout réimporter ?

Justement c'est pour ça qu'il vaut mieux que tu développes ta
fonctionnalité dans ta propre branche. De cette manière, tu reviens à
la branche "intacte" de SPIP, que tu "up" à partir des modifs récentes
faites par les core-devs. Quand tu juges que ta branche de travail n'a
plus d'utilité car le patch a été intégré/adapté/rejeté/etc., tu la
vires.

(alors que je m'en fous à ce moment, je veux qu'il écrase ma version
modifiée par la version modifiée du core pour repartir sur la "base
saine").

C'est ça. C'est pour ça les branches.