Quelques rectifications : XGL c'est le backend OpenGl d'X, Compiz c'est le gestionnaire de fenêtre. le mail que tu cites abordes donc les problèmes de Compiz et non pas de XGL ce qui fait une grosse différence.
Le dev de XGL était ouvert et David Reveman n'était pas le seul dev actif sur ce projet. Vu le nombre de codeurs au total qui se tient à l'aise sur les doigts d'une main l'argument comme quoi les discussions et explications font perdre du temps ne s'applique pas ici. Surtout quand l'architecture globale de XGl est déjà pas mal définie et que les autres participants en connaissent autant.
Ce qui est regrettable ce n'est pas que Novell est offert à emploi à temps plein à David pour bosser sur son bébé, ça tout le monde s'en était réjoui à l'époque. Le problème est d'avoir pris le code sous le bras et d'avoir forker dans une chambre noire, non seulement en excluant les autres devs mais en ne leur donnant aucunes informations (ne serait-ce que l'existence du projet interne). Ils ont par là même perdu des opportunités de peer review par les rares autres types assez calé sur le sujet.
En comparant avec ce mail à propos de Compiz et en essayant de voir où les arguments en faveur de son fork pourrait s'appliquer à XGL, on se rend rapidement compte qu'aucun ne s'y colle :
- endless debate : ce n'était pas le cas sur la list xorg, à part les trolls de Jon Smirl appellant à tuer EXA
- design by committee : il était déjà fait
- design by very small teams : XGL chez Novell c'était un one-man show, au sein de Xorg c'était déjà une very small team
- l'ouverture n'aurait rien empêché vu qu'il y avait un consensus sur la nécessité de XGL
Il n'y avait pas à mon sens de raisons techniques et organisationnelles pouvant motivé un fork fermé, la seul raison compréhensible étant de s'assurer l'exclusivité des "wooow" en étant les premiers à en faire la démonstration.
Ce n'est pas répréhensible en soi mais le groupe des devs Xorg est déjà suffisament restreint pour diviser ses forces encore plus. Si chaque contributeur individuel ou entreprise se met à lâcher une bombe de code après des mois en solitaire, je doute que le dev général s'en porterait mieux.
Là dans la press release tout parait simple et sans douleur mais ça serait oublier le gros travail d'intégration et de ré-écriture qu'ont du fournir dave arilie et eric anholt pour intégrer le code de david reveman dans le tronc principal d'X.org.
# Y a une erreur
Posté par Jean Roc Morreale . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 10.
Le dev de XGL était ouvert et David Reveman n'était pas le seul dev actif sur ce projet. Vu le nombre de codeurs au total qui se tient à l'aise sur les doigts d'une main l'argument comme quoi les discussions et explications font perdre du temps ne s'applique pas ici. Surtout quand l'architecture globale de XGl est déjà pas mal définie et que les autres participants en connaissent autant.
Ce qui est regrettable ce n'est pas que Novell est offert à emploi à temps plein à David pour bosser sur son bébé, ça tout le monde s'en était réjoui à l'époque. Le problème est d'avoir pris le code sous le bras et d'avoir forker dans une chambre noire, non seulement en excluant les autres devs mais en ne leur donnant aucunes informations (ne serait-ce que l'existence du projet interne). Ils ont par là même perdu des opportunités de peer review par les rares autres types assez calé sur le sujet.
En comparant avec ce mail à propos de Compiz et en essayant de voir où les arguments en faveur de son fork pourrait s'appliquer à XGL, on se rend rapidement compte qu'aucun ne s'y colle :
- endless debate : ce n'était pas le cas sur la list xorg, à part les trolls de Jon Smirl appellant à tuer EXA
- design by committee : il était déjà fait
- design by very small teams : XGL chez Novell c'était un one-man show, au sein de Xorg c'était déjà une very small team
- l'ouverture n'aurait rien empêché vu qu'il y avait un consensus sur la nécessité de XGL
Il n'y avait pas à mon sens de raisons techniques et organisationnelles pouvant motivé un fork fermé, la seul raison compréhensible étant de s'assurer l'exclusivité des "wooow" en étant les premiers à en faire la démonstration.
Ce n'est pas répréhensible en soi mais le groupe des devs Xorg est déjà suffisament restreint pour diviser ses forces encore plus. Si chaque contributeur individuel ou entreprise se met à lâcher une bombe de code après des mois en solitaire, je doute que le dev général s'en porterait mieux.
Là dans la press release tout parait simple et sans douleur mais ça serait oublier le gros travail d'intégration et de ré-écriture qu'ont du fournir dave arilie et eric anholt pour intégrer le code de david reveman dans le tronc principal d'X.org.