Lionel Debroux (./3) :
3) Naturellement, tu as des preuves qu'il ne se passe rien dans notre fork ?

Ce que je vois, c'est qu'il n'y a rien de visible, et que tu as refusé de me montrer ce que vous avez, ce qui me laisse présager que vous bluffez et que vous n'avez rien en réalité.


Quant à tes contributions, je reconnais avoir fait une erreur: l'erreur d'avoir accepté les contributions en ce format et d'avoir pensé avoir le temps et la motivation de les mettre en l'ordre moi-même. Comme tu peux le voir, ça n'a pas été le cas pendant ces 5 années et ça ne risque pas d'être le cas maintenant. Bref, j'aurais dû faire ce que font tous les grands projets libres (GCC etc.): refuser la contribution clairement parce qu'elle est inexploitable sous cette forme. Et c'est ce que je fais maintenant.

Lionel, visiblement, tu as plus de temps que moi actuellement, donc je ne vois pas pourquoi ce serait à moi de nettoyer ce que tu n'as soi-disant pas eu le temps de nettoyer. Tes contributions ne pourront être mergées que si tu:
* les relis! J'ai ouvert un seul fichier hier soir et ce fichier était faux (au point d'être inutilisable - d'ailleurs, il y a aussi le nom "TaskId" qui est bizarre dans ton prototype, le handle est un AppId, n'est-ce pas?), ce qui correspond à un taux d'erreur de 100%.
* les testes! Strict minimum, que les définitions proposées pour les headers compilent, ce qui n'a pas été le cas de certaines contributions déjà mergées.
* les rends compilables avec les outils de documentation! Ou si vraiment c'est trop de travail, tu peux aussi faire la refonte des outils de documentation qui est nécessaire (je propose de 1. porter le code existant vers du C/C++ et 2. rajouter les fonctionnalités qu'il nous faut, par exemple une hash table de toutes les fonctions pour qu'on puisse les référencer rapidement sans devoir spécifier le header à chaque fois). et enfin
* les découpes en morceaux les plus indépendants possible et mergeables l'un après l'autre! Notamment, si le patch A contient des références à des fonctions documentées dans le patch B qui vient après A dans la série et si ces fonctions sont dans unknown.h quand le patch B n'a pas encore été appliqué, alors le patch A doit garder les références vers unknown.h et c'est au patch B de mettre à jour la référence! C'est ce problème qui m'a empêché de faire un merge progressif de tes modifications, tout dépend de tout à cause des références. Là encore, une refonte des outils de documentation peut probablement aider.

Si tout ceci n'est pas fait, alors j'ai bien peur que tes contributions ne seront jamais mergées, je n'ai plus la motivation de faire ton travail à ta place (dans des projets comme GCC ou le noyau Linux, ce genre d'aménagements sont inéquivoquablement le boulot du contributeur, pas du mainteneur, je ne vois pas pourquoi TIGCC devrait être différent). Et je retiens qu'une documentation incomplète (et j'inclus les prototypes dans les headers dans "documentation" dans ce contexte) est moins grave qu'une documentation fausse, la qualité est plus importante que la quantité.


Et je voulais justement éviter ce débat inutile, mais il fallait forcément que tu rajoutes ton grain de sel partout. (Et Flanker aussi, alors que lui, on ne l'a carrément pas sonné! )