6:33 p.m.
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
10:18 a.m.
Zut je n'avais pas vu le thread;
comme dit dans l'autre thread, j'avais retenté une fois (avec l'espoir que
ça marcherait du premier coup) mais ça a échoué (pas les bons hashes == je
serais obligé de tout écraser l'existant, avec comme effet que tous ceux
qui ont basé des patches dessus auraient des problèmes).
J'ai une bonne idée du pourquoi et je vais réessayer.
Clairement cette fois je vais documenter histoire que d'autres puissent
s'en occuper aussi...
2015-04-19 18:33 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
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
3:39 p.m.
2015-04-20 11:07 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
Le 20 avril 2015 10:18, Julien Wajsberg <felash(a)gmail.com> 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
Je ne sais pas trop... pas avant jeudi soir en tout cas :/
7:38 p.m.
Ok, tiens-nous au courant. Bon courage !
Le 20 avr. 2015 3:40 PM, "Julien Wajsberg" <felash(a)gmail.com> a écrit :
2015-04-20 11:07 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
> Le 20 avril 2015 10:18, Julien Wajsberg <felash(a)gmail.com> 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
>
>
Je ne sais pas trop... pas avant jeudi soir en tout cas :/
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
8:38 a.m.
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 seul (BIG) problème est toujours le même : si on décidait de faire ça il
faudrait que quelqu'un se consacre à cette migration en n'oubliant pas de
récupérer au passage l'historique, les tickets et autres trucs associés.
Je n'ai pas l'impression qu'on dispose de cette ressource...
8:53 a.m.
on essaie de se voir à un moment pour discuter de vive voix de tout ça ?
m'est avis qu'on déciderait plus vite de ce qui est le mieux pour le projet.
Je peux ouvrir une salle de réunion à Mozilla un soir si vous voulez.
(je reviens juste de 10 jours en écosse sans aucune connexion donc voilà)
2015-05-18 8:38 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
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 seul (BIG) problème est toujours le même : si on décidait de faire ça il
faudrait que quelqu'un se consacre à cette migration en n'oubliant pas de
récupérer au passage l'historique, les tickets et autres trucs associés.
Je n'ai pas l'impression qu'on dispose de cette ressource...
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
9:50 a.m.
Le 18 mai 2015 08:38, Kozlika <kozlika(a)gmail.com> a écrit :
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).
…
serait une bonne chose parce que ?
10:35 a.m.
Argument rejeté vot'z'honneur !
Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
Le 18 mai 2015 09:50, Franck Paul
<carnet.franck.paul(a)gmail.com> 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
11:53 a.m.
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> a écrit :
Argument rejeté vot'z'honneur !
Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
> Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com> 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
12:23 p.m.
+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>:
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> a écrit :
> Argument rejeté vot'z'honneur !
>
> Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
>
> > Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com> 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
12:30 p.m.
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>:
+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>:
> 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> a
écrit :
>
> > Argument rejeté vot'z'honneur !
> >
> > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
> >
> > > Le 18 mai 2015 09:50, Franck Paul <carnet.franck.paul(a)gmail.com> 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
1:09 p.m.
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 ?
Faudrait aussi se donner un planning réaliste en fonction des ressources
dispos.
Je ne veux pas paraître pessimiste mais j'ai dans l'idée qu'on ne verra pas
plus de contrib' sur Github que lorsque c'était une fourmilière il y a 2
ans et que le dépôt Github était synchro là-bas — 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> 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>:
> +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>:
>
> > 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> a
> écrit :
> >
> > > Argument rejeté vot'z'honneur !
> > >
> > > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
> > >
> > > > Le 18 mai 2015 09:50, Franck Paul
<carnet.franck.paul(a)gmail.com> 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
1:45 p.m.
Le 18 mai 2015 13:09, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
[...] qui ?
Voilà, c'est ce que je disais dans mon mail initial ce matin. Je suis
convaincue sur le fond mais je ne crois pas qu'on ait les ressources
humaines assorties. A moins qu'il y ait quelqu'un sur cette liste que ça
amuse (je dis "que ça amuse" parce que vu le boulot que ça représente il
vaudrait mieux y trouver du plaisir :-)
2:25 p.m.
Le 18 mai 2015 13:09, Franck Paul <carnet.franck.paul(a)gmail.com> a écrit :
Voilà qui est mieux question arguments :-)
J'suis pas fort en 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 ?
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à !!!!
— le dev d'un moteur de
blog en PHP n'est plus du tout sexy de nos jours. On verra bien.
On ne verra certainement pas plus de contrib mais ceux qui verront le
projet ne repartiront pas directement. En clair, quand je vois "Rarely
sync'ed repository with... non official..." je pars direct. Cela ne donne
franchement pas envie.
Le 18 mai 2015 12:30, Julien Wajsberg <felash(a)gmail.com> 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>:
>
> > +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>:
> >
> > > 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> a
> > écrit :
> > >
> > > > Argument rejeté vot'z'honneur !
> > > >
> > > > Le 18 mai 2015 10:02, Nicolas <nikrou77(a)gmail.com> a écrit :
> > > >
> > > > > Le 18 mai 2015 09:50, Franck Paul
<carnet.franck.paul(a)gmail.com>
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
2:30 p.m.
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 !
2:54 p.m.
Le 18 mai 2015 14:30, Kozlika <kozlika(a)gmail.com> a écrit :
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 !
Tout à fait. Mais il y a une différence entre migrer et assurer la synchro.
La quantité d'énergie dépensée n'est pas la même.
Je n'étais pas présent lors de la migration subversion vers mercurial mais
l'historique n'a pas été conservé !
5:26 p.m.
On 18/05/15 14:25, Nicolas wrote:
> 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 ?
Bàv
--
Pinkilla
pb(à)namok.be
http://pit.namok.be / http://blog.namok.be
7:50 p.m.
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.
Nicolas
8:22 p.m.
2015-05-19 19:50 GMT+02:00 Nicolas <nikrou77(a)gmail.com>:
>
>
> 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.
et c'est pas plus de boulot.
2:55 p.m.
2015-05-18 13:09 GMT+02:00 Franck Paul <carnet.franck.paul(a)gmail.com>:
Voilà qui est mieux question arguments :-)
Donc on va :
- installer un Gitlab sur un serveur Dotclear : qui ?
Installer, c'est facile; mais maintenir c'est plus de boulot.
Surtout si (comme tu as essayé) un paquet debian n'est pas suffisant.
Faut-il essayer de migrer les tickets exisants? Juste les ouverts ou aussi
les fermés?
(mon avis: copier les ouverts -- en espérant qu'il n'y en ait pas trop).
- migrer tout l'historique des dépôts (DC et CB) sur Gitlab et
Github : qui
?
Historique des dépôts, si c'est du one time, c'est simple avec les outils
que j'ai cités.
Si on n'a pas besoin de trop long terme je peux d'ailleurs me focaliser sur
le premier outil que j'avais essayé (et que je connais assez bien à
présent) et mettre en place une synchro régulière (1 ou 2 par jour ?) le
temps de la migration.
- 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) ?
Il faut aussi avoir les "recettes" pour commiter au bon endroit (car comme
aujourd'hui un seul repo sera maître).
- 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 ?
Une fois qu'on a fait une synchro c'est trivial de rajouter un autre point.
j'oublie des choses ou pas ?
Faudrait aussi se donner un planning réaliste en fonction des ressources
dispos.
3 p.m.
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
"Fermer" (ou en tout cas ne pas y permettre autre chose q'une synchro)
bitbucket.
MAIS nos tickets c'est Trac il me semble. Donc même pas bitbucket. Pour ça
j'ai trouvé ça https://github.com/trustmaster/trac2github
Bon, le QUI reste entier. J'avoue que j'aurais bien tenté l'affaire
histoire de jouer à tout casser mais la refonte est déjà un gros bébé
joufflu...
3:02 p.m.
Apparemment on peut aussi brancher le Trac sur le Github
https://github.com/trac-hacks/trac-github
7:44 p.m.
2015-05-18 15:02 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
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
et on devrait garder les tickets et les changesets associés
--
Bruno
7:47 p.m.
Le 21 mai 2015 19:44, Bruno <dsls(a)morefnu.org> a écrit :
2015-05-18 15:02 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
> 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
changeset
avec les tickets...
--
Bruno
10:05 p.m.
2015-05-21 19:47 GMT+02:00 Bruno <dsls(a)morefnu.org>:
> * On convertit le bitbucket de hg vers git
Ce bout là, il est fait à la main avec fast-export, l'outil que j'ai
utilisé aussi. Le seul outil un peu automatique est celui qui sur github
permet d'importer depuis bitbucket. Mais je ne sais pas si ça importe aussi
les tickets. (m'étonnerait)
3:06 p.m.
2015-05-18 15:00 GMT+02:00 Kozlika <kozlika(a)gmail.com>:
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
En fait ça utilise la technique que j'ai (mieux :p) documenté dans mon mail
précédent.
Ce qui m'embête c'est qu'on ne va a priori pas faire tout d'un seul coup;
il faut d'abord avoir un git à jour avec un trac (ou autres) branché dessus
avant de pouvoir dire "ok, on passe à git".
Ou alors on passe un week-end à faire que ça, avec pour but qu'à la fin du
week-end c'est fini.
Puis cloner de bitbucket vers github
Apparemment on peut aussi brancher le Trac sur le Github
https://github.com/trac-hacks/trac-github
J'avoue que ça me semble une idée séduisante.
Une autre possibilité est d'avoir un repo git (sans gitlab et tout ça qui
vont autour) chez dotclear et brancher trac dessus. Frank avait regardé il
me semble ?
12:04 a.m.
Je ne fais pas avancer le schmilblick pour le qui, mais argument pour git
purement égoïste, je suis en formation git en ce moment !
Le 18 mai 2015 22:16, Kozlika <kozlika(a)gmail.com> a écrit :
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
7:43 a.m.
Le 19 mai 2015 00:04, Luce Carevic <luce.carevic(a)gmail.com> a écrit :
Je ne fais pas avancer le schmilblick pour le qui, mais argument pour
git
purement égoïste, je suis en formation git en ce moment !
Je ne sais pas si c'est valable mais je trouve que c'est un bon argument !
:-)
Le 18 mai 2015 22:16, Kozlika <kozlika(a)gmail.com> a écrit :
> 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
>
--
Dev mailing list - Dev(a)list.dotclear.org -
http://ml.dotclear.org/listinfo/dev
3273
days inactive
3305
days old
30 comments
8 participants
participants (8)
-
Bruno -
Franck Paul -
Julien Wajsberg -
Kozlika -
Luce Carevic -
Nicolas -
Pierre Equoy -
Pinkilla