Lionel: tes trolls ad hominem, tu peux les garder pour toi. Les facteurs qui ont mené à l'état actuel de la communauté n'ont rien à voir avec le comportement d'une personne, que ce soit moi ou même toi d'ailleurs.

Quant à la vitesse à laquelle j'intègre les contributions, ben les contributions que je reçois se classent en 2 catégories:
* documentation, souvent pas prête à être mergée telle quelle (cf. cross-references, mais il y a aussi souvent des fautes de grammaire, des imprécisions, des address hacks qui ne fonctionnent pas, des versions minimales de AMS incorrectes (genre 1.01 quand 1.00 suffit) etc.). Donc le merge d'un tel fichier de documentation nécessite de:
1. tester les address hacks (sur tous les AMS concernés), les corriger si nécessaire,
2. tester la version minimale de AMS nécessaire pour le address hack, la corriger si nécessaire,
3. relire le texte de la documentation, corriger les fautes d'anglais et de contenu et harmoniser la mise en forme avec le style de la documentation existante
4. mettre à jour les cross-references dans toute la documentation
J'estime environ 1 heure de travail (par fichier, c'est-à-dire par fonction!) pour les tests (1. et 2.), 1 heure pour la relecture et les corrections (3.) et 1 heure pour les cross-references (4.), donc 3 heures de travail par fonction! C'est loin d'être négligeable.
Et souvent les fonctions qui sont documentées dans ces contributions sont déjà utilisables avec leur prototype de unknown.h, donc c'est un pur ajout de documentation. Je retiens que les améliorations au compilateur lui-même sont beaucoup plus importantes. Pour la documentation manquante, on peut consulter celle de TIFS et/ou la version qui est dans contrib.zip.
* optimisations minimes, qui gagnent 2 octets sur une fonction en ASM de TIGCCLIB (intérêt quasiment nul), et en général l'optimisation n'a même pas été testée par celui qui l'envoie (ou alors il n'est pas précisé si, comment et avec quoi ça a été testé, donc c'est comme si les tests n'avaient pas été faits), donc il faut là aussi un temps non-négligeable pour les tests de régressions.

Je ne reçois quasiment aucune contribution vraiment utile:
* corrections de bogues! (De loin les plus importantes!) Il reste des bogues dans A68k par exemple, personne ne s'en occupe.
* optimisations majeures (sur une fonction ASM, c'est 10 octets strict minimum (et encore), mais l'idéal, c'est d'améliorer les optimisations dans le compilateur parce que du coup toutes les fonctions C en profitent, y compris toutes les fonctions en C de TIGCCLIB), idéalement testées par le contributeur (je ne vois pas pourquoi ce serait à moi de tester les patches qu'on m'envoie - et pour que je puisse éviter de tester moi-même, il me faut un report précis des tests effectués).