Ne comprends-tu pas qu'accepter des patches complets seulement à moitié dégrade la qualité de votre projet?

Peut-on appeler "patches incomplets" le fait de comitter d'abord une série complète de patches qui concerne >90% des utilisateurs, avant de committer la même série complète de patches pour un outil différent qui concerne le complément d'utilisateurs ? Je ne suis pas convaincu.
Première chose: si on a merdé au niveau design quand on a fait la première série, en général, on le voit bien avant d'avoir fini la première série.
Deuxième chose: si la première série fonctionne bien, a un bon design mais que la deuxième série pose problème (implémentation, capacités du langage ou du framework), faut-il faire languir tout le monde d'une feature attendue, sous prétexte qu'il y a un problème avec une petite minorité d'utilisateurs ? Je ne suis pas forcément de cet avis-là.


Et puis bon, question qualité de ton projet, tu peux vraiment parler, toi... J'ai déjà parlé de l'indentation mixte des fichiers Delphi, mais il y a beaucoup mieux que ça.
Faire du code-and-fix (tu sais, l'approche enfantine essai-erreur, la "méthode" de développement qu'on utilisait avant que la notion de génie logiciel existe - c'est bien parce que ça ne fonctionnait pas qu'on a inventé le génie logiciel, il y a plus de 40 ans), à cause de la philosophie "commit early", c'est vraiment bien, oh
La nuit du 20061029 au 20061030, dans les 10 commits qui suppriment VTI pour mettre TIEmu à la place, 3 (30 % ) sont des commits du type code-and-fix: "Fix a Cism and a copy&paste bug in SendFiles.", "Fix compilation errors." et "Remove unused variables.".

Une approche de qualité aurait été:
* d'une part, de ne pas utiliser cette philosophie "commit early". C'est en effet un moyen bien connu de dégrader la qualité des commits, puisque cela conduit en pratique à "commit too early". Ailleurs que dans TIGCC, je vois cette philosophie avec certaines personnes dans mon boulot, qui font de temps en temps des commits de fonctionnalités, vite suivis de petits commits avec un effet et un message du style "oups fix compilation error".
* de refaire ta série de patches, après le feedback du fait que ça ne compilait pas, pour avoir du code qui builde à chaque point de la série de patches. Là, ça n'est pas le cas, et ce genre de séries de patches ne serait accepté ni du kernel Linux (mainline, -mm est un peu différent), ni de Wine, ni du fork de TIGCC (sauf peut-être en branch expérimentale ET de manière temporaire, puisque ça rend plus difficile les bisections...)... ni d'ailleurs de TIGCC (tu veux des patches bien faits, n'est-ce pas).


Bon, allez, je pense que j'ai fini moi aussi de discuter avec Kevin. Il a posté quelques trucs constructifs dans ce topic, mais là, il s'amuse surtout à ne faire que critiquer les autres pour ne pas respecter des critères subjectifs sur lesquels ils ont des opinions différentes des siennes, ou pour ne pas respecter (si tant est que cela soit vrai, il n'a aucun élément d'information là-dessus) des critères objectifs qu'il ne respecte pas lui-même.