Discussion:
[grisbi-devel] git, github, sourceforge
Rémi Cardona
2016-10-04 21:15:50 UTC
Permalink
Salut à tous,

Vue l'activité récente sur grisbi, je synchronise (toujours
manuellement) quasi quotidiennement le dépôt git de github avec celui de
SF, ce dernier étant toujours officiellement le dépôt unique et central.

Hors, lors de certaines synchronisations, je me rends compte que mon
miroir local, qui devrait être identique à github, ne l'est pas
systématiquement. Par exemple, ce soir:

# de SF vers chez moi

$ git remote update -p
[...]
14e1278..22b1e57 master -> master

# de chez moi vers github

$ git push
[...]
be7ae79..22b1e57 master -> master

Le(s) commit(s) entre 14e1278 et be7ae79 ont été poussés directement sur
github. Je n'ai pas tenté d'identifier l'auteur de ces commits,
j'imagine qu'il se reconnaitra :)

Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit particulier. Mais
afin justement d'éviter de douloureux problèmes, j'aimerais que l'on décide:

1) si github devient le dépôt central et unique de référence
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépôt SF une
bonne fois pour toute (je veux bien m'en occuper)

Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépôt git de github.

Prochain débat pour une autre fois: que faire de mantis.

Salutations :-)

Rémi
Jean-Luc Duflot
2016-10-05 08:37:01 UTC
Permalink
Bonjour,
Post by Rémi Cardona
Salut à tous,
Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit particulier. Mais
1) si github devient le dépôt central et unique de référence
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépôt SF une
bonne fois pour toute (je veux bien m'en occuper)
Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépôt git de github.
Si le code est migré de SF vers github, que deviendrait le contenu de
https://sourceforge.net/projects/grisbi/files/ ?
Je pense à l'historique des versions, mais aussi à la documentation...

J'ai bien noté qu'il faudra mettre à jour la doc pour les liens. Ce
n'est pas un gros travail, mais est-il bien nécessaire de faire une
nouvelle version pour ça ? Alors qu'on pourrait peut-être soit garder
SF, soit mettre un lien de SF vers github ? Et de toutes façons j'aurai
à faire une nouvelle version, beaucoup plus lourde en modifications,
pour l'arrivée de GTK3 dans le code. Et là, je pourrai mettre le tout
sur github.

Jean-Luc
Post by Rémi Cardona
Prochain débat pour une autre fois: que faire de mantis.
Salutations :-)
Rémi
--
N'hésitez pas à consulter le manuel, c'est étudié pour ! (:-)
http://sourceforge.net/projects/grisbi/files/Documentation/
Ludovic Rousseau
2016-10-05 09:18:02 UTC
Permalink
Bonjour,

J'imagine que le coupable de tes « problÚmes » est moi :-)
Pour l'instant je pousse vers github et aussi vers sourceforge. Mais
j'imagine qu'un jour je vais oublier de pousser vers sourceforge. Et là...
Post by Jean-Luc Duflot
Bonjour,
Salut à tous,
Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit particulier. Mais
afin justement d'éviter de douloureux problÚmes, j'aimerais que l'on
1) si github devient le dépÎt central et unique de référence
Je vote pour.
Post by Jean-Luc Duflot
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépÎt SF une
bonne fois pour toute (je veux bien m'en occuper)
Bonne idée.
Post by Jean-Luc Duflot
Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépÎt git de github.
Si le code est migré de SF vers github, que deviendrait le contenu de
https://sourceforge.net/projects/grisbi/files/ ?
Je pense à l'historique des versions, mais aussi à la documentation...
L'idée n'est pas de fermer le projet sur sourceforge, juste de changer de
dépÎt git de référence.
Les fichiers déjà présents sur sourceforge ne vont pas disparaitre et on
peut continuer à en ajouter.

D'ailleurs je note sur sourceforge propose toujours un dépÎt CVS du code
source https://sourceforge.net/p/grisbi/cvs/ qui n'a pas bougé depuis
longtemps :-)

J'ai bien noté qu'il faudra mettre à jour la doc pour les liens. Ce n'est
Post by Jean-Luc Duflot
pas un gros travail, mais est-il bien nécessaire de faire une nouvelle
version pour ça ? Alors qu'on pourrait peut-être soit garder SF, soit
mettre un lien de SF vers github ? Et de toutes façons j'aurai à faire une
nouvelle version, beaucoup plus lourde en modifications, pour l'arrivée de
GTK3 dans le code. Et là, je pourrai mettre le tout sur github.
La migration sourceforge -> github ne concerne que les développeurs. Les
autres ressources de grisbi ne changent pas

Prochain débat pour une autre fois: que faire de mantis.
Bonne question.
Je viens de voir que Mantis est toujours utilisé.
Pour l'instant le projet github n'a pas la section "Issues" ouverte donc il
n'est pas possible de rapporter un bug sur github.

à+
--
Dr. Ludovic Rousseau
Jean-Luc Duflot
2016-10-05 13:42:57 UTC
Permalink
En fait, j'attendais une réponse de Pierre, qui a vue sur le code et sur
ce que j'ai fait sur la doc. mais tu as été le plus rapide !

JL
Post by Jean-Luc Duflot
Bonjour,
J'imagine que le coupable de tes « problèmes » est moi :-)
Pour l'instant je pousse vers github et aussi vers sourceforge. Mais
j'imagine qu'un jour je vais oublier de pousser vers sourceforge. Et là...
Bonjour,
Salut à tous,
Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit
particulier. Mais
afin justement d'éviter de douloureux problèmes, j'aimerais que
1) si github devient le dépôt central et unique de référence
Je vote pour.
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépôt SF une
bonne fois pour toute (je veux bien m'en occuper)
Bonne idée.
Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépôt git de github.
Si le code est migré de SF vers github, que deviendrait le contenu
de https://sourceforge.net/projects/grisbi/files/
<https://sourceforge.net/projects/grisbi/files/> ?
Je pense à l'historique des versions, mais aussi à la documentation...
L'idée n'est pas de fermer le projet sur sourceforge, juste de changer
de dépôt git de référence.
Les fichiers déjà présents sur sourceforge ne vont pas disparaitre et on
peut continuer à en ajouter.
D'ailleurs je note sur sourceforge propose toujours un dépôt CVS du code
source https://sourceforge.net/p/grisbi/cvs/ qui n'a pas bougé depuis
longtemps :-)
J'ai bien noté qu'il faudra mettre à jour la doc pour les liens. Ce
n'est pas un gros travail, mais est-il bien nécessaire de faire une
nouvelle version pour ça ? Alors qu'on pourrait peut-être soit
garder SF, soit mettre un lien de SF vers github ? Et de toutes
façons j'aurai à faire une nouvelle version, beaucoup plus lourde en
modifications, pour l'arrivée de GTK3 dans le code. Et là, je
pourrai mettre le tout sur github.
La migration sourceforge -> github ne concerne que les développeurs. Les
autres ressources de grisbi ne changent pas
Prochain débat pour une autre fois: que faire de mantis.
Bonne question.
Je viens de voir que Mantis est toujours utilisé.
Pour l'instant le projet github n'a pas la section "Issues" ouverte donc
il n'est pas possible de rapporter un bug sur github.
à+
--
Dr. Ludovic Rousseau
--
N'hésitez pas à consulter le manuel, c'est étudié pour ! (:-)
http://sourceforge.net/projects/grisbi/files/Documentation/
Pierre Biava
2016-10-05 20:30:00 UTC
Permalink
Rémi Cardona a écrit le 04/10/2016 à 23:15 :

Bonsoir,
Post by Rémi Cardona
Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit particulier. Mais
1) si github devient le dépôt central et unique de référence
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépôt SF une
bonne fois pour toute (je veux bien m'en occuper)
Ne connaissant pas GitHub, j'y ai jeté un œil. J'ai compris que la
"philosophie" de ce projet n'est pas la même que celle de SF.

Jusqu'à présent le fonctionnement était libre et chaque volontaire
pouvait commiter sans formalité particulière. Il suffisait de faire la
demande et/ou d’avoir un compte sur SF pour intégrer les développeurs de
grisbi. La sortie se faisant tout aussi facilement.


Si on peut continuer à faire comme ça sur Github mais j'ai un doute,
c'est Ok pour moi. Je pense qu'on n'est pas assez nombreux pour mettre
en place une organisation industrielle.
Post by Rémi Cardona
Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépôt git de github.
Prochain débat pour une autre fois: que faire de mantis.
Je pense qu'il serait bien qu'on fasse une réunion virtuelle avec un
outil qui conviendrait à Ludovic afin de listerà minima ce qu'il
convient de faire dans les prochains mois pour modifier l’hébergement du
projet et sortir une version gtk3 de grisbi.

Bonne soirée.
--
A+

Pierre Biava
Ludovic Rousseau
2016-10-05 21:01:29 UTC
Permalink
Post by Pierre Biava
Bonsoir,
Fort heureusement, les modifications poussées sur github le sont aussi
sur SF et donc tout rentre dans l'ordre, sans conflit particulier. Mais
afin justement d'éviter de douloureux problÚmes, j'aimerais que l'on
1) si github devient le dépÎt central et unique de référence
2) le cas échéant, que l'ont "ferme" (avec un commit local qui ne
laisserait qu'un maigre README pointant vers github) le dépÎt SF une
bonne fois pour toute (je veux bien m'en occuper)
Ne connaissant pas GitHub, j'y ai jeté un œil. J'ai compris que la
"philosophie" de ce projet n'est pas la même que celle de SF.
Jusqu'à présent le fonctionnement était libre et chaque volontaire pouvait
commiter sans formalité particuliÚre. Il suffisait de faire la demande
et/ou d’avoir un compte sur SF pour intégrer les développeurs de grisbi. La
sortie se faisant tout aussi facilement.
Si on peut continuer à faire comme ça sur Github mais j'ai un doute, c'est
Ok pour moi. Je pense qu'on n'est pas assez nombreux pour mettre en place
une organisation industrielle.
Tu as as raison. Le process normal sur github est que n'importe qui peut
proposer des modifications en faisant des Pull Request (PR). Le(s)
mainteneur(s) du projet relis(ent) le code proposé et accepte ou refuse le
code.

Mais on peut trÚs bien utiliser github de la même ma maniÚre que
sourceforge en donnant un accÚs à qui le demande. Dans ce cas il est
possible à chacun de pousser ses modifications directement.

Pour l'instant il y a 3 personnes qui peuvent pousser du code sur le dépÎt
github.
Post by Pierre Biava
Il faudra, j'imagine, également mettre à jour le site web et la
documentation pour faire référence au dépÎt git de github.
Prochain débat pour une autre fois: que faire de mantis.
Je pense qu'il serait bien qu'on fasse une réunion virtuelle avec un outil
qui conviendrait à Ludovic afin de listerà minima ce qu'il convient de
faire dans les prochains mois pour modifier l’hébergement du projet et
sortir une version gtk3 de grisbi.
L'email me convient.
IRC (ou un truc en temps réel) est plus problématique car je ne peux pas
garantir des créneaux de disponibilité (vie familiale, travail, etc.)

On peut aussi utiliser des outils de Framasoft (que je n'ai pas encore
utilisés) comme
- Framemo
https://framablog.org/2016/09/09/framemo-un-tableau-pour-vos-tempetes-de-cerveaux/
- Framapad https://framapad.org/
- Framaboard https://framaboard.org/

à+
--
Dr. Ludovic Rousseau
Rémi Cardona
2016-10-20 10:30:06 UTC
Permalink
Post by Pierre Biava
Je pense qu'il serait bien qu'on fasse une réunion virtuelle avec un
outil qui conviendrait à Ludovic afin de listerà minima ce qu'il
convient de faire dans les prochains mois pour modifier
l’hébergement du projet et sortir une version gtk3 de grisbi.
L'email me convient.
IRC (ou un truc en temps réel) est plus problématique car je ne peux pas
garantir des créneaux de disponibilité (vie familiale, travail, etc.)
Je pratique irc en asynchrone: j'ai un serveur allumé 24h/24 où tourne
mon client irc. Cela me permet de lire les canaux irc à n'importe quel
moment de la journée (ou de la nuit, merci à bébé…)

Les discutions se font ainsi au fil de l'eau. Vu l'activité quasi-nulle
du canal irc, il y est très facile d'y causer, même sur plusieurs jours.
Post by Pierre Biava
On peut aussi utiliser des outils de Framasoft (que je n'ai pas encore
utilisés) comme
- Framemo
https://framablog.org/2016/09/09/framemo-un-tableau-pour-vos-tempetes-de-cerveaux/
- Framapad https://framapad.org/
- Framaboard https://framaboard.org/
Je pratique le pad, ça peut être une idée. Je ne connais pas les autres,
je regarde.

Rémi
Rémi Cardona
2016-10-20 10:10:48 UTC
Permalink
Post by Pierre Biava
Ne connaissant pas GitHub, j'y ai jeté un œil. J'ai compris que la
"philosophie" de ce projet n'est pas la même que celle de SF.
Jusqu'à présent le fonctionnement était libre et chaque volontaire
pouvait commiter sans formalité particulière. Il suffisait de faire la
demande et/ou d’avoir un compte sur SF pour intégrer les développeurs de
grisbi. La sortie se faisant tout aussi facilement.
On peut tout à faire garder ce mode de fonctionnement avec github.

Mais on peut aussi utiliser *en plus*, tout ou partie des
fonctionnalités proposées par github.

Par exemple, faire des PRs depuis un dépôt forké. Cela permet de lancer
des discutions thématiques autour de propositions de code. Ce que
j'avais tenté de faire sur la ML sans grande réussite. :)

Par contre, je n'aime pas du tout laisser l'interface de github faire
des commits/merges à ma place. Sur un autre projet libre que je
co-maintiens [1], je fais des rebases des PRs que je pousse à la main
dans master, sans toucher à l'IHM de github. J'aime bien garder un
historique le plus linéaire possible.

Moralité: à nous de décider ce que l'on veut faire !
Post by Pierre Biava
Si on peut continuer à faire comme ça sur Github mais j'ai un doute,
c'est Ok pour moi. Je pense qu'on n'est pas assez nombreux pour mettre
en place une organisation industrielle.
Au contraire, le système de PR de github permet de faciliter les
contributions ponctuelles/occasionnelles sans avoir à ajouter de gens à
la liste des commiteurs du projet => moins de boulot administratif.

Rémi

[1] https://github.com/Polyconseil/aioamqp
Ludovic Rousseau
2016-10-20 13:17:30 UTC
Permalink
Post by Pierre Biava
Ne connaissant pas GitHub, j'y ai jeté un œil. J'ai compris que la
"philosophie" de ce projet n'est pas la même que celle de SF.
Jusqu'à présent le fonctionnement était libre et chaque volontaire
pouvait commiter sans formalité particuliÚre. Il suffisait de faire la
demande et/ou d’avoir un compte sur SF pour intégrer les développeurs de
grisbi. La sortie se faisant tout aussi facilement.
On peut tout à faire garder ce mode de fonctionnement avec github.
Mais on peut aussi utiliser *en plus*, tout ou partie des
fonctionnalités proposées par github.
Par exemple, faire des PRs depuis un dépÎt forké. Cela permet de lancer
des discutions thématiques autour de propositions de code. Ce que
j'avais tenté de faire sur la ML sans grande réussite. :)
Par contre, je n'aime pas du tout laisser l'interface de github faire
des commits/merges à ma place. Sur un autre projet libre que je
co-maintiens [1], je fais des rebases des PRs que je pousse à la main
dans master, sans toucher à l'IHM de github. J'aime bien garder un
historique le plus linéaire possible.
Moralité: à nous de décider ce que l'on veut faire !
Pour récupérer simplement les commits des Pull Request j'ai trouvé
https://gist.github.com/piscisaureus/3342247

Du coup les modif sont directement disponible dans le dépÎt local et
peuvent être mergées par "git cherry-pick".
TrÚs pratique.

à+
--
Dr. Ludovic Rousseau
Loading...