[grisbi-devel] Migration du code source de sourceforge à github ?

[Ludovic Rousseau]

Bonjour,

Est-ce que quelqu'un s'oppose à la migration du dépÎt git du code source de
sourceforge vers github ?

Je trouve github bien plus pratique à utiliser que sourceforge.
- possibilité de forker facilement le code et de suivre la trace des forks
- possibilité de faire des Pull Requests et de les lire/commenter avant
merge
- possibilité d'utiliser facilement des outils d'intégration contiue (
https://travis-ci.org/)

J'ai cherché comment synchroniser automatiquement de github vers
sourceforge mais ça ne semble pas immédiat. Donc il est probable qu'il
faille abandonner le dépÎt git de sourceforge.


Je postule pour être membre/admin de l'organisation grisbi
https://github.com/grisbi
ainsi que membre/admin du dépÎt grisbi https://github.com/grisbi/grisbi

Rémi, peux-tu me donner les accÚs STP ? mon login github est LudovicRousseau
https://github.com/LudovicRousseau

à+

[Pierre Biava]

Post by Ludovic Rousseau
Bonjour,
Est-ce que quelqu'un s'oppose à la migration du dépôt git du code
source de sourceforge vers github ?
Je trouve github bien plus pratique à utiliser que sourceforge.
- possibilité de forker facilement le code et de suivre la trace des forks
- possibilité de faire des Pull Requests et de les lire/commenter
avant merge
- possibilité d'utiliser facilement des outils d'intégration contiue
(https://travis-ci.org/)

Je n'y suis pas opposé dans la mesure ou ça ne me contraint pas plus que
SF. Je travaille sur grisbi depuis 2007 par plaisir et parce que la
communauté est sympathique. Je voudrais que ça continue.

Cdt.

[Rémi Cardona]

Post by Ludovic Rousseau
Bonjour,
Est-ce que quelqu'un s'oppose à la migration du dépôt git du code source
de sourceforge vers github ?

Je suis pour!

Post by Ludovic Rousseau
Je trouve github bien plus pratique à utiliser que sourceforge.
- possibilité de forker facilement le code et de suivre la trace des forks
- possibilité de faire des Pull Requests et de les lire/commenter avant
merge
- possibilité d'utiliser facilement des outils d'intégration contiue
(https://travis-ci.org/)
J'ai cherché comment synchroniser automatiquement de github vers
sourceforge mais ça ne semble pas immédiat. Donc il est probable qu'il
faille abandonner le dépôt git de sourceforge.

Actuellement, je fais la synchro SF→github à la main avec un dépôt git
en mode "mirror" spécialement configuré. Pénible parce qu'il faut le
faire à la main, mais la synchro se fait en deux commandes. J'aurais du
faire un cron pour automatiser tout ça, mais comme il n'y a eu que très
peu de commits jusqu'à ces dernières semaines, je n'ai pas eu de
motivation extérieure pour l'automatiser.

Je ne suis pas un grand fan de github, je lui trouve plein de défauts. MAIS:

* SF a été très peu fiables ces dernières années, surtout son interface
web (heureusement, la partie git pure est restée plutôt stable)
* notre Mantis est dans un état catastrophique, je n'y vais plus
* l'IHM de github est meilleure que celle de mantis (argument des plus
subjectifs, je reconnais)
* ça ferait un système en moins à maintenir
* facteur mode pour attirer des contributeurs, même occasionnels
(drive-by commits), ça m'attriste mais c'est une réalité
* travis serait sympa mais on a tellement pas/peu de tests unitaires que
je trouve l'argument pas convaincant en l'état. D'autre part, je ne sais
pas comment ça se passe pour lui faire compiler du gtk (à creuser?)
* github sait héberger les binaires associés à une release (les .exe
windows par ex), c'était à une époque un gros plus de SF par rapport à
github
* github est activement développé et maintenu (des gens payent pour la
version pro, contrairement à SF) ce qui est plutôt bon signe pour l'avenir

L'autre solution à laquelle j'avais pensé était de nous rattacher à
gnome.org pour leur infrastructure, ayant un projet gtk, ça se
tiendrait. Toutefois, les gens de Gnome se posent aussi les mêmes
questions pour faciliter les contributions externes. Donc pas forcément
le meilleur choix du monde (même si amha, c'est toujours mieux que
SF+mantis)

Post by Ludovic Rousseau
Je postule pour être membre/admin de l'organisation grisbi
https://github.com/grisbi
ainsi que membre/admin du dépôt grisbi https://github.com/grisbi/grisbi
Rémi, peux-tu me donner les accès STP ? mon login github est
LudovicRousseau https://github.com/LudovicRousseau

Invitation lancée via github, la balle est dans ton camp!

Mais pour l'instant, c'est *uniquement* un miroir de SF!

Bonne soirée,

Rémi

[Ludovic Rousseau]

Post by Rémi Cardona

Post by Ludovic Rousseau
Bonjour,
Est-ce que quelqu'un s'oppose à la migration du dépÎt git du code source
de sourceforge vers github ?

Je suis pour!
* travis serait sympa mais on a tellement pas/peu de tests unitaires que
je trouve l'argument pas convaincant en l'état. D'autre part, je ne sais
pas comment ça se passe pour lui faire compiler du gtk (à creuser?)

Travis-CI est configuré.
Les résultats sont sur https://travis-ci.org/grisbi/grisbi
<https://travis-ci.org/LudovicRousseau/grisbi>

J'ai corrigé deux erreurs de compilation.
Maintenant le build échoue au link.

Les Pull Requests sur github devraient aussi passer par Travis-CI. Ça
permet de vérifier automatiquement si un patch proposé compile ou non.

à+

[Gérald Niel]

Le Mercredi 21 septembre 2016 à 20:34 UTC, Rémi Cardona écrivait sur

Post by Rémi Cardona
Invitation lancée via github, la balle est dans ton camp!

Moi je suis là :
https://github.com/gegeweb

@+

[Ludovic Rousseau]

Le Mercredi 21 septembre 2016 à 20:34 UTC, Rémi Cardona écrivait sur

Invitation lancée via github, la balle est dans ton camp!

https://github.com/gegeweb

Invitation lancée.

à+

[Ludovic Rousseau]

Post by Ludovic Rousseau
Bonjour,
Est-ce que quelqu'un s'oppose à la migration du dépÎt git du code source
de sourceforge vers github ?
Je trouve github bien plus pratique à utiliser que sourceforge.
- possibilité de forker facilement le code et de suivre la trace des forks
- possibilité de faire des Pull Requests et de les lire/commenter avant
merge

Mais il faut maintenant lire les PR et les accepter ou les refuser. Y'en a
3 en attente.

Post by Ludovic Rousseau
- possibilité d'utiliser facilement des outils d'intégration contiue (
https://travis-ci.org/)

En fait l'utilisation de Travis-CI n'a pas été aussi simple que prévu.

Travis utilise Ubuntu 12.04 par défaut et 14.04 à la demande. Pour utiliser
Ubuntu 16.04 et avoir un gtk+3 récent j'ai utilisé Docker. Et comme c'est
ma premiÚre utilisation de Docker j'ai peut-être fait super complexe et
quelqu'un peut simplifier.

Une des limitations de la configuration actuelle est que les PR ne passent
pas par Travis. Ce qui est pourtant super pratique.

Je veux bien l'avis d'un connaisseur Docker sur mon utilisation dans
https://github.com/grisbi/grisbi/blob/master/.travis.yml

à+

[Ludovic Rousseau]

Post by Ludovic Rousseau
En fait l'utilisation de Travis-CI n'a pas été aussi simple que prévu.
Travis utilise Ubuntu 12.04 par défaut et 14.04 à la demande. Pour

utiliser Ubuntu 16.04 et avoir un gtk+3 récent j'ai utilisé Docker. Et
comme c'est ma premiÚre utilisation de Docker j'ai peut-être fait super
complexe et quelqu'un peut simplifier.

Post by Ludovic Rousseau
Une des limitations de la configuration actuelle est que les PR ne

passent pas par Travis. Ce qui est pourtant super pratique.

Post by Ludovic Rousseau
Je veux bien l'avis d'un connaisseur Docker sur mon utilisation dans

https://github.com/grisbi/grisbi/blob/master/.travis.yml

AprÚs lecture de documentation sur Docker et découverte de cette
technologie à la mode j'ai refais la configuration pour Travis-CI.
Maintenant les Pull Requests reçues sur github devraient être soumise à
Travis-CI et donc on sait tout de suite si le code proposé compile ou non.

J'ai ajouter un fichier README.md avec une icÃŽne indiquant le status
Travis-CI directement sur la page principale de github
https://github.com/grisbi/grisbi

à+

--
Dr. Ludovic Rousseau