Hého, Julien, tu te souviens que tu dois synchroniser les dépôts ? Je te propose de convenir d'un jour/heure cette semaine où nous nous retrouverons sur IRC et tu décriras comment tu fais pour que je note la procédure et qu'on soit capables de le refaire les autres fois, si tu n'en as pas le temps. Merci ! -- Anne / Kozlika -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Le 20 avril 2015 10:18, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : > Clairement cette fois je vais documenter histoire que d'autres puissent > s'en occuper aussi... > Super ! Puis-je me permettre de demander quand ? :-P

Histoire de remettre un euro dans le nourrin : je suis personnellement plutôt convaincue que disposer du dépôt en Git et être présents sur Github serait une bonne chose (en parallèle d'un miroir sur nos serveurs ou vice-versa).

Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > ​serait une bonne chose parce que ? ​ > Parce que git rend la peau douce est brillante ! -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Arguments "objectifs" : * plus de facilité à trouver de la doc sur Git que sur Mercurial, * la possibilité de récupérer l'historique de commits perso (je sais pas expliquer, je parle de reflog) * pour github : la plus grande familiarité pour de potentiels nouveaux venus Sur le plan strictement technique, je sais bien qu'on trouvera des avantages supérieurs à l'un ou à l'autre selon les sujets. D'ailleurs... https://www.hackerearth.com/notes/prasoon2211/mercurial-vs-git-scaling-an... La vraie clé c'est Github, qui qu'on le veuille ou non est une sorte d'incontournable des projets Open Source. Je crois qu'être présents sur Github pour de vrai (pas avec une grosse alerte "le vrai dépôt nest pas celui-là") et le fameux bouton "clone/fork" avec l'octopus en bas des pages de notre site est une démonstration côté comm qu'on est encore dans le coup et que les contributeurs sont bienvenus. Si un jour nous avions de nouveaux les moyens humains, Git permettrait aussi soit sur github soit via un gitlab d'y transférer la doc intégrée, voire toute la doc, via les gitpages. Le 18 mai 2015 10:35, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a écrit : > Argument rejeté vot'z'honneur ! > > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > > > Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit : > > > > > serait une bonne chose parce que ? > > > > > > > Parce que git rend la peau douce est brillante ! > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Franck > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Anne / Kozlika -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Sans parler des avantages de git vs mercurial (parce qu'après tout les 2 ont des avantages et inconvénients), je suis d'accord avec ce qu'a dit Koz sur la présence sur github. Certes y être présents ne nous amènera pas magiquement de nouveaux core contributeurs, mais à mon avis ça rend la contribution occasionnelle plus facile. 2015-05-18 12:23 GMT+02:00 Pierre Equoy <pierre.equoy(a)gmail.com&gt;: > +1 pour tout ce qu'a dit Koz. > > En bonus : > - la staging area de Git > - les commits partiels intégrés de base > - git blame! \o/ > > En outre, GitHub n'est pas *encore* le mal incarné, et même quand il le > deviendra, tout l'historique du projet est stocké en local chez quiconque a > fait un fork chez soi, donc le code n'est pas difficile à migrer. > > 2015-05-18 17:53 GMT+08:00 Kozlika <kozlika(a)gmail.com&gt;: > > > Arguments "objectifs" : > > > > * plus de facilité à trouver de la doc sur Git que sur Mercurial, > > * la possibilité de récupérer l'historique de commits perso (je sais pas > > expliquer, je parle de reflog) > > * pour github : la plus grande familiarité pour de potentiels nouveaux > > venus > > > > Sur le plan strictement technique, je sais bien qu'on trouvera des > > avantages supérieurs à l'un ou à l'autre selon les sujets. D'ailleurs... > > > > > https://www.hackerearth.com/notes/prasoon2211/mercurial-vs-git-scaling-an... > > > > La vraie clé c'est Github, qui qu'on le veuille ou non est une sorte > > d'incontournable des projets Open Source. Je crois qu'être présents sur > > Github pour de vrai (pas avec une grosse alerte "le vrai dépôt nest pas > > celui-là") et le fameux bouton "clone/fork" avec l'octopus en bas des > pages > > de notre site est une démonstration côté comm qu'on est encore dans le > coup > > et que les contributeurs sont bienvenus. > > > > Si un jour nous avions de nouveaux les moyens humains, Git permettrait > > aussi soit sur github soit via un gitlab d'y transférer la doc intégrée, > > voire toute la doc, via les gitpages. > > > > > > Le 18 mai 2015 10:35, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > écrit : > > > > > Argument rejeté vot'z'honneur ! > > > > > > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > > > > > > > Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > > > écrit : > > > > > > > > > serait une bonne chose parce que ? > > > > > > > > > > > > > Parce que git rend la peau douce est brillante ! > > > > -- > > > > Dev mailing list - Dev(a)list.dotclear.org - > > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > > > > > > -- > > > Franck > > > -- > > > Dev mailing list - Dev(a)list.dotclear.org - > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > -- > > Anne / Kozlika > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > > > > -- > Pierre Equoy > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Voilà qui est mieux question arguments :-)

Donc on va : - installer un Gitlab sur un serveur Dotclear : qui ? - migrer tout l'historique des dépôts (DC et CB) sur Gitlab et Github : qui ? - prévoir un atelier pour les ceusse qui ont un peu utilisé Hg mais pas du tout Git : qui pilote ça (je verrai bien Kozlika pour ça) ? - mettre en place les hooks qui vont bien pour synchroniser tout ce beau monde : qui ? - et tant qu'à faire, puisque Bitbucket gère aussi des dépôts Git, maintenir une synchro là-bas (a priori je ne vois pas pourquoi on disparaîtrait de là) : qui ? j'oublie des choses ou pas ?

— le dev d'un moteur de blog en PHP n'est plus du tout sexy de nos jours. On verra bien.

Le 18 mai 2015 12:30, Julien Wajsberg <felash(a)gmail.com&gt; a écrit : > Sans parler des avantages de git vs mercurial (parce qu'après tout les 2 > ont des avantages et inconvénients), je suis d'accord avec ce qu'a dit Koz > sur la présence sur github. Certes y être présents ne nous amènera pas > magiquement de nouveaux core contributeurs, mais à mon avis ça rend la > contribution occasionnelle plus facile. > > > 2015-05-18 12:23 GMT+02:00 Pierre Equoy <pierre.equoy(a)gmail.com&gt;: > > > +1 pour tout ce qu'a dit Koz. > > > > En bonus : > > - la staging area de Git > > - les commits partiels intégrés de base > > - git blame! \o/ > > > > En outre, GitHub n'est pas *encore* le mal incarné, et même quand il le > > deviendra, tout l'historique du projet est stocké en local chez > quiconque a > > fait un fork chez soi, donc le code n'est pas difficile à migrer. > > > > 2015-05-18 17:53 GMT+08:00 Kozlika <kozlika(a)gmail.com&gt;: > > > > > Arguments "objectifs" : > > > > > > * plus de facilité à trouver de la doc sur Git que sur Mercurial, > > > * la possibilité de récupérer l'historique de commits perso (je sais > pas > > > expliquer, je parle de reflog) > > > * pour github : la plus grande familiarité pour de potentiels nouveaux > > > venus > > > > > > Sur le plan strictement technique, je sais bien qu'on trouvera des > > > avantages supérieurs à l'un ou à l'autre selon les sujets. > D'ailleurs... > > > > > > > > > https://www.hackerearth.com/notes/prasoon2211/mercurial-vs-git-scaling-an... > > > > > > La vraie clé c'est Github, qui qu'on le veuille ou non est une sorte > > > d'incontournable des projets Open Source. Je crois qu'être présents sur > > > Github pour de vrai (pas avec une grosse alerte "le vrai dépôt nest pas > > > celui-là") et le fameux bouton "clone/fork" avec l'octopus en bas des > > pages > > > de notre site est une démonstration côté comm qu'on est encore dans le > > coup > > > et que les contributeurs sont bienvenus. > > > > > > Si un jour nous avions de nouveaux les moyens humains, Git permettrait > > > aussi soit sur github soit via un gitlab d'y transférer la doc > intégrée, > > > voire toute la doc, via les gitpages. > > > > > > > > > Le 18 mai 2015 10:35, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > > écrit : > > > > > > > Argument rejeté vot'z'honneur ! > > > > > > > > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com&gt; a écrit : > > > > > > > > > Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com&gt; a > > > > écrit : > > > > > > > > > > > serait une bonne chose parce que ? > > > > > > > > > > > > > > > > Parce que git rend la peau douce est brillante ! > > > > > -- > > > > > Dev mailing list - Dev(a)list.dotclear.org - > > > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > > > > > > > > > > > -- > > > > Franck > > > > -- > > > > Dev mailing list - Dev(a)list.dotclear.org - > > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > > > > > > -- > > > Anne / Kozlika > > > -- > > > Dev mailing list - Dev(a)list.dotclear.org - > > > http://ml.dotclear.org/listinfo/dev > > > > > > > > > > > -- > > Pierre Equoy > > -- > > Dev mailing list - Dev(a)list.dotclear.org - > > http://ml.dotclear.org/listinfo/dev > > > -- > Dev mailing list - Dev(a)list.dotclear.org - > http://ml.dotclear.org/listinfo/dev > -- Franck -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

Nicolas, on a de toutes façons besoin de ne rien perdre ni de l'historique du dépôt, ni de celui des tickets et des releases, quelles que soient les décisions pour l'avenir. Le gros point noir ça n'est pas tellement le dépôt, c'est tout ce qu'il y a autour !

Pour ce qui concerne les sources j'ai trouvé ça http://www.wordsinboxes.com/2012/02/migrating-repositories-from-bitbucket... en gros : Depuis bitbucket, transformer de mercurial à git

Puis cloner de bitbucket vers github

Apparemment on peut aussi brancher le Trac sur le Github https://github.com/trac-hacks/trac-github

Xave, ça ne te brancherait pas de faire ça dans les semaines/mois qui viennent ? -- Dev mailing list - Dev(a)list.dotclear.org - http://ml.dotclear.org/listinfo/dev

> Donc on va : > > - installer un Gitlab sur un serveur Dotclear : qui ? > - (…) > j'oublie des choses ou pas ? Il y a un truc que je ne comprends pas : quel est l'intérêt de faire toutes ces synchros mis à part se donner encore plus de boulot ? On n'a pas assez de bras, on mange moins de chocolat ! Cela ne tiendrait qu'à moi, le dépôt serait sur github et c'est tout. Après on peut faire un hook pour qu'il soit dupliqué automatiquement sur un serveur dotclear. Le réel avantage d'utiliser github c'est qu'on ne se préoccupe pas de la maintenance. L'argument pour dire que si github est cassé on ne peut plus commiter ne tient pas. Je pense que le taux d'indisponibilité est très très faible et de plus on ne commite pas à ce point là !!!!

> > > Salut, > > Je ne comprends pas bien l'utilité de toutes les synchros non plus si ce > n'est de donner de la visibilité au projet. > > Si dotclear se trouve sur github (ou bitbucket), ça donne moins de boulot > à l'équipe. > > Tu parles d'un hook pour dupliquer sur un serveur dotclear, ne serait-ce > pas plus simple qu'une tâche cron sur un serveur dotclear fasse un pull > tous les jours ? > L'avantage du hook c'est que c'est tout le temps à jour.

2015-05-18 15:02 GMT+02:00 Kozlika <kozlika(a)gmail.com&gt;: > Apparemment on peut aussi brancher le Trac sur le Github > https://github.com/trac-hacks/trac-github > > En fait c'est plus sioux que ça. Dans l'approche : * On synchronise le bitbucket de dc avec le hg de dc (ça doit déjà être le cas) * On exporte les tickets du trac via http://bb.secdev.org/trac2bitbucket * On importe les tickets dans le bitbucket de dc * On convertit le bitbucket de hg vers git * ensuite on importe le tout dans github : https://github.com/tugberkugurlu/bitbucket-issues-to-github Oubliez ce que j'ai dit, bitbucket n'assure pas la transition des