Tout d'abord, on se calme hein, pas la peine d'être aussi agressif.
Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).
Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.
[^] # Re: workflows
Posté par rewind (Mastodon) . En réponse au journal Git malgré moi. Évalué à 3.
Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).
Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.