Yoshi Noir (./175) :
Mais bordel, c'est pas le fait que ton chan soit en UTF-8 qui pose problème, c'est le fait que TU KICKES ET QUE TU BANNIS EN PARTANT DU PRINCIPE QUE TOUT NOUVEAU VENU QUI N'A PAS RÉGLÉ SON CLIENT IRC EN UTF-8 EST POTENTIELLEMENT UN NUISIBLE !!!!

Non, je kicke (et je bannis parce que certains clients rejoignent automatiquement après un kick) pour éviter que d'autres messages soient postés en un charset incorrect. Le ban est levé dès que le problème de configuration est résolu, CE N'EST PAS une sanction! (La sanction, c'est le ban de longue durée que je mets si on fait exprès de poster en non-UTF-8.)

Lionel Debroux (./176) :
Parmi les quatre liens que tu cites sur le fait d'apporter ton "expertise" à propos des chaînes d'outils, les deux du milieu sont intéressants, mais du même topic, et le dernier est une direction à ne prendre qu'au mieux dans un second temps, après avoir fait en sorte que le gdbstub (qui offre à l'utilisateur le choix du debugger compatible gdbstub qu'il veut utiliser, et réduit la maintenance [EDIT: de l'émulateur, je veux dire]) fonctionne

Je rajouterai aussi des considérations de stabilité. Effectivement, l'architecture choisie pour le débogeur de TIGCC n'est pas forcément optimale. Voyant comment ExtendeD a réalisé rapidement la communication par stub, cette solution m'a effectivement l'air intéressante, mais il reste à voir la qualité de l'intégration. (Je suis particulièrement sceptique face au choix d'utiliser une chaîne d'outils sans aucun patch, ça empêche d'apporter certaines modifications qui ont été très bénéfiques pour TIGCC, autant pour GDB que par exemple pour GCC.)

(Au fait, si tu trouves que l'architecture par stub soit tellement meilleure, à quand un TiEmu basé sur cette architecture? )

je ne pense pas que tu sois totalement exclu de la communauté Nspire pour le futur. Mais probablement jamais en tant que décideur

Je crois fermement en le principe de la méritocratie et donc je ne suis pas prêt à contribuer à un projet si on me dit d'avance qu'on ne me confiera jamais des responsabilités, quel que soit le travail fourni dans le projet. Je ne suis pas disponible pour être exploité par un groupe qui compte me tenir dans une cage. Si j'investis mon temps dans un projet, j'attends aussi d'avoir le respect qui va avec!

Même dans les entreprises commerciales, il y a (presque) toujours la possibilité d'une promotion, sinon les employés ne seraient pas motivés à travailler même pour de l'argent. Cette motivation est d'autant plus importante quand il s'agit de travail fourni volontairement sans aucune récompense pécuniaire.

Le fait que tu fasses maintenant campagne contre le FESCo ( par exemple, http://lists.fedoraproject.org/pipermail/devel/2010-August/140855.html ), dont tu faisais partie il n'y a pas si longtemps mais où tu n'es rien parvenu à changer car tu étais nettement minoritaire ( à part ta lettre ouverte au FESCo, citons http://lists.fedoraproject.org/pipermail/devel/2010-August/140985.html ), est très révélateur...

Révélateur du fait que le FESCo est un échec et qu'on ne peut pas changer le système de l'intérieur, donc qu'une révolution est inévitable.

Le principal problème du FESCo est qu'il n'est pas méritocratique. Un contributeur qui vient d'intégrer le projet à exactement la même voix dans les élections qu'un packageur expert avec des dizaines de paquetages à son actif. Les SIGs, eux, fonctionnent beaucoup mieux (par exemple, il y a beaucoup moins de conflits au niveau des SIGs!) et ont une structure naturellement méritocratique. Je trouve donc qu'ils formeraient un système de gouvernement du projet beaucoup plus juste que la structure artificielle formée par le FESCo et le Fedora Project Board. Le fait qu'il y ait besoin d'élections montre déjà l'artificialité de cette structure. Dans un gouvernement de projet libre qui fonctionne bien, les personnes s'y retrouvent automatiquement grâce au travail fourni dans le projet et tout le monde comprend pourquoi, accepte et est d'accord avec le fait qu'elles soient là. S'il y a besoin d'élections, c'est que la structure guide du projet est contestée, ce qui est signe d'un mauvais fonctionnement.

A dire vrai, je ne suis pas convaincu qu'après des années de "je vais faire ça", "il faudrait que je fasse ça", "il faudrait faire ça", et puis rien (entre bien d'autres, dans la news ticalc qui annonçait GCC4TI au début de 2009, ton post contenant un truc du genre "There will be a release of TIGCC with the same fixes and more soon" n'a été suivi d'aucun effet), il y ait encore grand monde qui compte sur toi

Ne comprends-tu pas que c'est à cause de posts comme le tien auquel je réponds ici que je ne suis plus motivé pour TIGCC? Et aussi que le peu de temps que j'ai pu et voulu mettre dans les projets TI, j'ai été obligé de le mettre dans le renommage des projets CalcForge que je dois faire à cause de toi? (Au début de 2009, je ne savais pas encore que j'allais devoir faire ça!) Je mettais pratiquement tout mon temps libre dans TIGCC, mais c'est face à une communauté 1. de plus en plus petite (donc de moins en moins d'utilisateurs potentiels) et 2. de plus en plus désagréable (et tu y es pour beaucoup dans ça!) que mes priorités ont changé. De plus, comme toi, je vois que TiLP et/ou CalcForgeLP ont nettement plus d'utilisateurs (actuels et potentiels) que TIGCC et/ou GCC4TI, donc j'y apporte une priorité plus élevée (mais aussi faible à cause des démotivateurs comme toi).

(Cela dit, les réformes récentes dans le projet Fedora qui détruisent au fur et à mesure tout ce qui était bien dans le projet sont aussi très efficaces pour me démotiver de ça et pourraient au final faire que je me retrouve à passer plus de temps sur TIGCC…)