Lionel Debroux (./168) :
la création d'un repository Git a été motivée par le fait d'utiliser de vrais outils de SCM

Plutôt le fait de faire le développement en privé pour m'empêcher de voir ce que vous faites, n'est-ce pas?

Quand les seuls commits dans ton dépôt sont les miroirs de mes commits dans le CVS, forcément c'est soit ça, soit vous n'avez rien foutu en tout ce temps, au choix.

Faudra vraiment pas vous plaindre si je rends mon CVS privé en tout cas, vu que vous faites pareil.

C'est du moins ce que tu crois

Comme je l'ai toujours dit, pour moi, ce qui n'est pas public n'existe pas. Ça ne change rien en pratique qu'il y ait des améliorations privées auxquelles la communauté n'a pas accès.

A part la présence quasi-exclusive de code Delphi, réécrire intégralement n'est pas forcément une nécessité, du moins à court et moyen termes. Deux défauts que je connais ne nécessitent aucun changement aux exécutables Delphi, l'un se corrige par un one-liner et j'ai commencé à m'attaquer à l'autre pas plus tard que tout à l'heure (parce qu'il y en a besoin pour le fork, de toute façon).

Bon, OK, il y a 2 manières de corriger le problème: le bidouillage, rajoutant des outils supplémentaires pour essayer de contourner les limitations des outils existants, ou la refonte qui corrige réellement ces limitations, et qui rend aussi les outils maintenables (en l'absence d'un mainteneur pour du code Delphi). Je sais que tu as toujours défendu la première solution, mais c'est la mauvaise solution à long terme, tu ne peux pas éviter toutes les limitations comme ça, et tu risques d'introduire de nouveaux problèmes.

En cours où? Sur ton dépôt git?

Non, comme tu peux d'ailleurs le voir toi-même. Je te renvoie une nouvelle fois à topics/108648-ld-tigcc-flash-os-bss-special/5#120

Message qui ne contient aucun pointeur vers un dépôt autre que ton miroir git de mon CVS. Donc il ne répond pas à ma question.

'Convenablement', j'ai écrit. Ca n'est vraiment pas l'impression que tu donnes...

Si pour toi, "convenablement" = "en acceptant immédiatement et sans discussion tous les patches qu'on envoie, même s'ils ne documentent pas les ajouts, s'ils nécessitent des corrections manuelles pour être appliquables aux sources actuelles (genre pour les callgraphs dans tes patches de documentation), s'ils sont incomplets (cf. toujours les callgraphs), s'ils n'ont pas été testés, si les patches sont une mauvaise idée et/ou s'ils créent des problèmes non résolus", alors non, mais si tu utilises la vraie définition de ce mot, alors si. (Certains des problèmes, genre les corrections manuelles à apporter ou l'absence de tests effectués, vont retarder l'acceptance parce qu'il faut que je fasse votre boulot et que ça prend du temps, pour d'autres, comme un patch qui est fondamentalement défectueux, un rejet total s'impose malheureusement.)

Pour le système de doc, tant que le code Delphi tourne sous Wine (c'est le cas) ET qu'on n'a pas besoin de le modifier, à la limite, on s'en fiche.

Le problème, c'est qu'on a besoin de le modifier, et radicalement! Cf. plus haut.

La sensibilité aux line endings (CR LF obligatoire), par exemple ? C'est une limitation importante, mais elle est facile à contourner.

Oui, c'est facile de la contourner en bidouillant, il suffit de lancer unix2dos, c'est ce que je fais évidemment, mais c'est de la bidouille, pour une vraie solution, il faut corriger l'outil!

, que veux-tu que je réponde d'autre ?

Rien, ça aurait été mieux que ta réponse qui est une bêtise...

Quand il y a quelques nostalgiques qui veulent absolument utiliser VTI alors qu'il gère mal les HW2 (il émule essentiellement une HW1 qui se fait passer pour HW2, ce qui fait que la détection du matériel de TIGCCLIB est obligée d'avoir un cas particulier pour VTI ), qu'il ne gère pas du tout les V200 et les Titaniums (on peut faire tourner leurs ROMs avec des hacks, mais ça n'émule pas leur matériel de manière fiable, le matériel émulé reste celui d'une HW1), que certaines fonctionnalités (affichages des handles, program entry breakpoints) ne fonctionnent pas avec AMS 3 et ne fonctionnent avec AMS 2 que si on utilise une version modifiée plus boguée que l'originale et dont les sources ont été perdues, que VTI ne propose aucun débogueur C et qu'il n'a pas été mis à jour depuis 2001 et quand ils prétendent que "la communauté veut utiliser VTI", je ne vois vraiment pas comment je devrais l'appeler autrement qu'"imposer leurs préférences personnelles en les faisant passer pour la volonté de la communauté".

Par exemple, un partage des tâches selon ce que chacun sait le mieux faire (toi: GCC, KTIGCC; d'autres: outillage et contenu documentation; d'autres: librairie; etc.) ?

J'ai toujours proposé un tel partage des tâches, mais dans le contexte de l'infrastructure existante, votre intégration à l'équipe étant progressive, pas immédiate (donc tous les patches devront être revus par un membre de l'équipe au départ - et je suis désolé, mais à moins que vous ne réussissiez à faire revenir un de mes anciens coéquipiers, ce sera moi au départ, mais une fois un nouveau membre intégré, il pourra aussi s'occuper des revues des patches des autres membres aspirants), et pas dans le but de revenir sur des décisions déjà prises (donc hors de question de remettre les hacks pour envoyer des programmes à VTI ou de mettre les plans de gris consécutifs sur HW1, cette dernière décision a d'ailleurs été prise en concordance avec Thomas, Sebastian et Zeljko, ce n'est pas mon choix personnel!). De plus, en tant que membre actif le plus ancien, je resterais évidemment tête du projet. C'est toujours ce que je vous ai à offrir, je ne suis pas partant pour autre chose.

C'est le système de la méritocratie, celui ou ceux qui fait/font le travail décide(nt), pour l'instant c'est moi qui ai travaillé sur TIGCC pendant des années, vous ne pouvez pas sortir de nulle part et vous attendre de pouvoir tout bouleverser du jour au lendemain.

Naturellement, mais on ne fait pas le fork pour t'empêcher d'utiliser nos modifs.

Alors je réitère ma question: où sont-elles?

On le sait parfaitement, et on sait qu'il y a un certain nombre de choses qui ne te plaisent pas beaucoup, pas du tout ou vraiment pas, que tu ne vas pas merger

Et donc je ne peux prendre votre invitation à participer à votre fork que pour ce qu'elle est: une mauvaise plaisanterie.

C'est pas parce que tu n'as pas vu les faits qu'il n'existent pas

Contradiction! (Et là le mot est bel et bien correct!) Si vous ne me montrez pas vos modifications, comment voulez-vous que je les utilise? Donc vous m'empêchez bel et bien de les utiliser.

Si tu ne veux pas me donner cette impression, ben c'est simple: j'attends toujours la réponse à la question: où sont vos modifs?

Faudrait peut-être demander leur avis aux autres committeurs sur le projet TIGCC ?

Qui? Romain qui a fait un seul commit dans un répertoire debian récemment? Je ne pense pas que ça le dérangerait énormément, on peut facilement packager sans avoir le répertoire debian directement dans le dépôt des sources. Sinon il n'y a personne d'autre qui a fait un commit récemment (le plus récent était probablement Konrad qui a fait quelques petits nettoyages dans KTIGCC 2, mais ça commence aussi à faire quelques mois).

Ça serait différent si vous acceptiez de participer dans le cadre de l'infrastructure existante, mais j'ai comme l'impression que ça ne vous intéresse pas...

Tu devrais aussi reporter l'utilisation de cvssuck à SourceForge et leur suggérer d'utiliser du filtrage, comme tu me l'avais suggéré une fois.

Bah, si je désactive le CVS de SF ou si j'arrête de le mettre à jour, ce ne sera de toute façon pas nécessaire.