Donc non clairement, ce n'est pas le workflow prévu par git.
J’ai dit Gi*s*t, pas Git.
Et sur le reste de ton message tu surinterprètes. Le truc que je dis être accepté (pifométriquement) par 99% des utilisateurs Git, c’est que le boulot se fait sur des branches fonctionnalités séparées et non pas directement sur master. Pour le reste, rebase vs merge, une branche par hotfix ou une unique branche hotfix, je sais bien qu’il y a autant d’opinions (tout aussi valables les unes que les autres) que de personnes, et non je dis pas que le workflow Github est LE workflow Git, d’autant plus que celui que j’ai mis en place au boulot en diffère substantiellement :)
Ce que je dis (et où je suis en profond désaccord), c’est que je trouve le workflow Github particulièrement adapté à ce qui m’intéresse pour comment j’aborde mes contributions aux logiciels libres : des petits patchs sur des projets, pas de grosses contributions qui demandent de grosses discussions, des tests/synchronisations fréquents, etc.
Le seul point qui a l’air de te chagriner c’est la multiplication des clones. Je ne vois pas du tout le problème : sauf très rares exceptions, le mainteneur c’est la racine de l’arbre. C’est une règle assez simple et claire je trouve.
D’un autre côté, la solution mailing list, ça veut dire :
- devoir s’inscrire à une mailing list (et les 3/4 des processus d’inscriptions aux ML sont ignoblement pénibles). Ça inclut choisir un mot de passe (genre je n’ai pas assez de mots de passe à gérer avec les 57 bugzilla et les 473 autres sites qui demandent une inscription...), et le risque (loin d’être négligeable puisque au final tout mail que tu envoies sur une ML se retrouvera broadacsté à des centaines voire des milliers d’inconnus) que le dit mail se retrouve dans la nature et devienne un nid à spams.
- faire chier 200 personnes qui n’en ont rien à faire de ton petit bug avec un message
- puis, pendant 2 mois, te faire spammer ta boîte mail avec des messages dont tu n’as que faire jusqu’à ce que tu aies le courage de suivre la procédure kafkaïenne de la mailing list pour te désincrire (et ce jusqu’au prochain bug)
Alors oui, si tu es un contributeur régulier les ML c’est cool. Oui, si le patch est important (grosse fonctionnalité) pouvoir en discuter en public c’est cool.
Pour des patchs d’une dizaine de lignes je préfère 100 fois deux clics sur une interface web
Avec ton exemple, je suis en effet totalement dans le flou
Mon exemple est un peu particulier dans le sens ou l’upstream a été obligé (DCMA notice) d’arrêter son dépôt, et qu’il peut donc difficilement désigner explicitement un repreneur sans se faire taper sur les doigts (et sans que ce repreneur lui-même aie le même problème).
Mais il illustre un autre avantage (mineur je le reconnais) de cette incitation au fork : même si un jour le dev initial décide (sur un coup de tête, problème légal,...) de tout supprimer, le code est toujours là. Avantage que n’auront pas les petits projets sur des trucs genre sourceforge.
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Moonz . En réponse au journal Pourquoi je contribue ?. Évalué à 1.
J’ai dit Gi*s*t, pas Git.
Et sur le reste de ton message tu surinterprètes. Le truc que je dis être accepté (pifométriquement) par 99% des utilisateurs Git, c’est que le boulot se fait sur des branches fonctionnalités séparées et non pas directement sur master. Pour le reste, rebase vs merge, une branche par hotfix ou une unique branche hotfix, je sais bien qu’il y a autant d’opinions (tout aussi valables les unes que les autres) que de personnes, et non je dis pas que le workflow Github est LE workflow Git, d’autant plus que celui que j’ai mis en place au boulot en diffère substantiellement :)
Ce que je dis (et où je suis en profond désaccord), c’est que je trouve le workflow Github particulièrement adapté à ce qui m’intéresse pour comment j’aborde mes contributions aux logiciels libres : des petits patchs sur des projets, pas de grosses contributions qui demandent de grosses discussions, des tests/synchronisations fréquents, etc.
Le seul point qui a l’air de te chagriner c’est la multiplication des clones. Je ne vois pas du tout le problème : sauf très rares exceptions, le mainteneur c’est la racine de l’arbre. C’est une règle assez simple et claire je trouve.
D’un autre côté, la solution mailing list, ça veut dire :
- devoir s’inscrire à une mailing list (et les 3/4 des processus d’inscriptions aux ML sont ignoblement pénibles). Ça inclut choisir un mot de passe (genre je n’ai pas assez de mots de passe à gérer avec les 57 bugzilla et les 473 autres sites qui demandent une inscription...), et le risque (loin d’être négligeable puisque au final tout mail que tu envoies sur une ML se retrouvera broadacsté à des centaines voire des milliers d’inconnus) que le dit mail se retrouve dans la nature et devienne un nid à spams.
- faire chier 200 personnes qui n’en ont rien à faire de ton petit bug avec un message
- puis, pendant 2 mois, te faire spammer ta boîte mail avec des messages dont tu n’as que faire jusqu’à ce que tu aies le courage de suivre la procédure kafkaïenne de la mailing list pour te désincrire (et ce jusqu’au prochain bug)
Alors oui, si tu es un contributeur régulier les ML c’est cool. Oui, si le patch est important (grosse fonctionnalité) pouvoir en discuter en public c’est cool.
Pour des patchs d’une dizaine de lignes je préfère 100 fois deux clics sur une interface web
Mon exemple est un peu particulier dans le sens ou l’upstream a été obligé (DCMA notice) d’arrêter son dépôt, et qu’il peut donc difficilement désigner explicitement un repreneur sans se faire taper sur les doigts (et sans que ce repreneur lui-même aie le même problème).
Mais il illustre un autre avantage (mineur je le reconnais) de cette incitation au fork : même si un jour le dev initial décide (sur un coup de tête, problème légal,...) de tout supprimer, le code est toujours là. Avantage que n’auront pas les petits projets sur des trucs genre sourceforge.