TiLP/TiEmu: arrêt du développement - Page 5

Je trouve très intéressant, très significatif, le fait que Kevin ait non seulement rapidement changé d'avis sur le renommage de son fork après que Romain l'ait flingué (page 2), mais aussi qu'il ait posté des news très "soft" (fussent-elles quand même mensongères par affirmation et par omission, il n'a apparemment pas pu s'empêcher...).

C'est clair qu'il n'est pas en position de force dans cette affaire, et il le sait très bien. Ne serait-ce parce que le fait qu'il nous est facile de pointer, faits à l'appui, que le déclenchement d'un fork est ENCORE de sa faute. En vérité, il déclenche ce fork parce qu'il est horriblement vexé de ne pas être considéré comme un bon mainteneur et qu'il est incapable de se remettre en cause, voir quelques posts au-dessus:

Tu sais très bien que j'ai l'intention de continuer ces projets auxquels je participe depuis des années, tu aurais pu (et franchement, dû) me désigner comme successeur sans que je le demande et dès le post de départ.

Je ne sais pas si je suis un bon mainteneur pour TILP et TIEmu - le temps le dira - mais je suis manifestement un moins mauvais mainteneur que Kevin. Ce n'est pas difficile, remarquez...

Refuser de renommer ses forks n'aurait fait qu'aggraver son cas vis à vis de la communauté internationale. A force d'accumuler connerie sur connerie, il arrive au résultat que de moins en moins de gens ignorent son côté sombre, qui est malheureusement de plus en plus présent...


Je sais que ça ne sert à rien de prêcher les membres habituels de ce forum (ils savent déjà, depuis le temps ), je poste ce qui suit pour référence: l'existence même de GCC4TI est majoritairement de la faute de Kevin, pas de celle des créateurs et planifieurs de GCC4TI.
J'en veux pour preuve les faits (qui sont têtus, comme vous le savez): la plupart des créateurs et planifieurs de GCC4TI ont eu de nombreuses et fructueuses collaborations / coopérations, avec diverses personnes de la communauté. Ces gens sont capables de coopérer, d'utiliser des outils appropriés pour ce faire.
Ce que n'est pas Kevin, comme on le lui reproche depuis des années, sans résultat...

A titre personnel: après que je lui aie envoyé plusieurs idées d'amélioration des programmes de TICT, et aussi quelques contributions au code, Thomas Nussbaumer m'a proposé d'_intégrer_ TICT, pour _renforcer_ l'équipe (j'avais plus de temps libre que lui, et j'étais intéressé par améliorer les programmes, comme je le lui avais prouvé). C'est exactement ce que Romain (et JB) viennent de faire pour TIEmu (et TILP) !
("méritocratie", Kevin ?)

Mais Thomas est quelqu'un de BEAUCOUP plus sympathique et raisonnable que ne l'est Kevin (ce n'est pas difficile ):
* Thomas a vu le fait qu'un nouveau membre pourrait apporter des choses (ce qui a été le cas, c'est un fait: optimisations, nouvelles features notamment dans TICT-Explorer, et aussi coopération avec des personnes extérieures qui ont contribué de grosses features - pour faire court en n'en citant qu'une, celle de Julien RF / Sasume à ExtGraph);
* Kevin a vu dans mon ajout (au début, il n'était pas question de le virer, juste d'ajouter une personne !) une menace, apparemment. Il refuse de faire des compromis, de partager la maintenance et par là de faire avancer la communauté au maximum du possible. Il a joué l'épreuve de force, posté des conneries... et il a perdu.


[EDIT: au fait, je n'ai pas relevé ./115...
Pourquoi devrais-je être "content" que tu aies condescendu à me mentionner ? Je ne suis pas aussi égocentrique que toi... heureusement !]

Le site des nouveaux projets est maintenant en ligne: http://www.calcforge.org/.

Et au fait, je n'ai rien "perdu" du tout. Les utilisateurs apprendront à connaître les nouveaux noms. Les utilisateurs des dépôts CalcForge pour Fedora et CentOS seront carrément mis à jour automatiquement. Votre projet est voué à mourir, vous n'avez même pas de tête de projet officielle (vu que Romain prétend (cf. ./116) t'avoir approuvé seulement comme développeur, pas comme son successeur) et le mainteneur de facto (toi) est un nouveau qui vient d'intégrer l'équipe juste avant le départ de Romain.

Notre projet est tellement mort que jusqu'à cette nuit, c'était le seul à proposer des bugfixes ayant été appliqués après la création de TILP-fork et TIEmu-fork

Un seul bugfix. L'autre commit est un changement d'URL, que je n'ai pas mergé parce que l'URL de votre SVN actuel est tout aussi fausse que l'autre pour nous et nous allons de toute façon corriger les URLs quand nous remplacerons les noms partout. De plus, un des fichiers que tu as corrigés est supprimé dans notre dépôt (J89hw.txt – je signale que l'auteur a interdit explicitement de copier ce fichier, il a été redistribué et modifié illégalement par Romain).

Il n'y a pas d'interdiction explicite de redistribution et modification dans J89hw.txt, même dans la version originale 200106040000. C'est à Johan Eilert que tu fais référence par "auteur" ?

Oui, il a toujours dit qu'il faut linker sur son site, pas copier le fichier, "pour que tout le monde ait la version la plus récente"… puis un jour il a arrêté de le mettre à jour. Le résultat, c'est ce que tu vois (des versions modifiées et redistribuées sans permission).

S'il voulait vraiment interdire la distribution, il n'avait qu'à le marquer dans son document, mais passons... Je l'ignorais, et je pense que Thomas aussi (c'est lui qui a mis la copie).

Le site de mise à jour de Johan Eilert (celui d'"Olle") n'existe plus...
Redistribuer des versions augmentées, comme le font le LPG (TIEmu) et TICT (qui héberge depuis longtemps une copie sur son site, que j'ai récemment mise à jour), est une façon de trouver d'autres canaux pour augmenter le partage de la connaissance.
Le site de TICT précise un autre point de mise à jour qui a été utilisé plus tard par la version de Johan Eilert... ce site n'existe plus non plus, il faut que je corrige ça.

Je sais encore que Johan s'est plaint à l'époque de la rediffusion sur tict.ticalc.org, je ne sais plus quelle était la conclusion, s'il a réellement autorisé Thomas à le rediffuser ou s'il l'a juste toléré (c'est-à-dire arrêté de s'en plaindre).

c'est quand même ridicule cette obsession a vouloir faire ce que tu veux.

pour info renseigne toi sur le sort de la glibc sur debian, ça serait rigolo que ça t'arrive aussi.

Que lui arrive-t-il ?

http://blog.aurel32.net/?p=47

http://sourceware.org/bugzilla/show_bug.cgi?id=5531
http://sourceware.org/bugzilla/show_bug.cgi?id=4980
http://sourceware.org/bugzilla/show_bug.cgi?id=4403
http://sourceware.org/bugzilla/show_bug.cgi?id=5070
http://sources.redhat.com/bugzilla/show_bug.cgi?id=3266
http://sources.redhat.com/bugzilla/show_bug.cgi?id=9901



(ça avait pas déja été posté?)

http://sourceware.org/bugzilla/show_bug.cgi?id=4980 est particulièrement impressionnant ^^

c'est du Kevin 2.0

Strange, I never saw your name on my paycheck. Since if that's not the case you
cannot order me around.

cte mauvaise foi ^^

Bah, ce sont juste des excuses, glibc est effectivement maintenue par Red Hat (au point où les releases de la glibc sont alignées avec celles de Fedora, si Fedora prend du retard, la glibc aussi ) et c'est bien ça qui dérange Debian, leur choix est de la pure politique. Le pauvre Ulrich Drepper ne leur sert que de bouc émissaire.

oooh le pauvre connard qui prend ses utilisateurs pour de la merde au lieu de se rappeler que c'est grâce a eux que les bugs sont trouvés

./135 : ouais, donc les releases de la glibc sont liées à son packaging sous fedora, et que le releasing de la glibc dépend de son packaging sous fedora ? (vu qu'elle prendrait du retard si fedora prend du retard)

Oui, les releases de glibc sont systématiquement quelques jours avant la release de Fedora, la release officielle de la glibc est toujours un des derniers freeze overrides de Fedora (mais Rawhide a des snapshots tout le long, donc le passage à la finale n'est pas un changement majeur). Cela fait que Fedora est toujours la première grande distribution à avoir la nouvelle glibc dans une release.

mais on s'en tape, non?

Kevin Kofler (./138) :
Oui, les releases de glibc sont systématiquement quelques jours avant la release de Fedora, la release officielle de la glibc est toujours un des derniers freeze overrides de Fedora (mais Rawhide a des snapshots tout le long, donc le passage à la finale n'est pas un changement majeur). Cela fait que Fedora est toujours la première grande distribution à avoir la nouvelle glibc dans une release.

Tu veux dire que Fedora prend en otage toutes les autres distrib linux ?

la Fée Dora (l'exploratrice) nous merde tous!

./139 : moi j'étais parti sur le fait que le packaging était fait en même temps que la release, et que donc dissocier release & packaging n'avait pas de sens dans ce cas, mais c'est vrai que pour le coup, ça veut dire que fedora conditionne les autres distribs, vu que linux est plutôt pas mal dépendant de la libc, et donc ça donne effectivement une raison supplémentaire à debian pour passer à autre chose

[troll]Vive Linux, Vive le LIbre, vive le choix, vive la libertée ![/troll]

De toute façon, les autres distribs avaient déjà systématiquement 2 versions de retard sur Fedora pour la glibc avant que les releases aient été synchronisées. Même si on fait abstraction sur le fait que les principaux développeurs de la glibc travaillent pour Red Hat, il serait quand-même dans leur intérêt de synchroniser leur release avec la distribution qui est de toute façon la seule grande distribution à suivre son développement et proposer la version la plus récente.

...qui contient des bugs que les mainteneurs refusent d'admettre ?

Kevin Kofler (./144) :
, il serait quand-même dans leur intérêt de synchroniser leur release avec la distribution qui est de toute façon la seule grande distribution à suivre son développement et proposer la version la plus récente.

Si la version la plus récente n'est disponible à temps que pour Red Hat, c'est normal que les autres distribs ne l'aient pas

Bon, j'ai perdu le fil de la scène TI-68K depuis un bon bout de temps et je souhaiterais qu'on me dise deux-trois trucs...

* Si j'ai bien compris, GCC4TI est un fork de TIGCC qui remet le support de VTI ?
* Quelle est la dernière version de TIGCC et quelles en sont les dernières features ?
* Si j'ai bien également compris, il existe deux verisons de TiEmu, une version avec l'émulation pure et dure, et une autre avec des interfaces de débug avec visualisation des registres, de l'état de la RAM et tutti quanti ? Quelle est la dernière version de TiLP et TiEmu ? Quelles en sont les dernières features ?
* Dernière question sans doute HS : est-ce que la doc de TIGCC explique enfin clairement la manipulation de fichiers sur TI et fournit une explication autre que "t'as qu'à mieux comprendre la doc, c*nnard !" ?

Rappel:

Kevin Kofler (./144) :
De toute façon, les autres distribs avaient déjà systématiquement 2 versions de retard sur Fedora pour la glibc avant que les releases aient été synchronisées.

Fedora est sortie avec glibc 2.4 dans une release stable (Feodra Core 5) avant qu'elle fasse son apparition même dans Debian experimental! Debian etch est sortie avec la glibc 2.3 alors que Fedora Core 6 était sortie avec la 2.5 depuis quelques mois à ce moment.

Les histoires de synchronisation des releases justifieraient au maximum une version de retard.

Yoshi Noir (./147) :
* Si j'ai bien compris, GCC4TI est un fork de TIGCC qui remet le support de VTI ?

À peu près. Ils comptent aussi accepter d'autres patches qui dégradent la qualité du code. La divergence augmentera de plus en plus.

* Quelle est la dernière version de TIGCC et quelles en sont les dernières features ?

0.96 Beta 8. La nouveauté principale était justement le passage à TiEmu dans TIGCC IDE. (D'ailleurs, il est prévu que Emu-TIGCC pourra être utilisé à la place de TiEmu sans aucune modification à TIGCC IDE.) Il y a du nouveau dans le CVS, il faut que je refasse une release.

* Si j'ai bien également compris, il existe deux verisons de TiEmu, une version avec l'émulation pure et dure, et une autre avec des interfaces de débug avec visualisation des registres, de l'état de la RAM et tutti quanti ?

Non, la version sans GDB a aussi ce débogueur bas niveau. La différence, c'est de pouvoir déboguer un programme C correctement (au niveau sources) (avec GDB) ou non (sans GDB).

Quelle est la dernière version de TiLP et TiEmu ?

TiLP2 1.13 et TiEmu 3.03. (Et il n'y a pas encore de releases de CalcForgeLP et Emu-TIGCC.)

Quelles en sont les dernières features ?

Corrections de bogues avant tout.

* Dernière question sans doute HS : est-ce que la doc de TIGCC explique enfin clairement la manipulation de fichiers sur TI et fournit une explication autre que "t'as qu'à mieux comprendre la doc, c*nnard !" ?

Je trouve que la documentation est claire, si tu as des améliorations à proposer, j'attends tes patches.

OK, pour les versions.
.

Kevin Kofler (./149) :
D'ailleurs, il est prévu que Emu-TIGCC pourra être utilisé à la place de TiEmu sans aucune modification à TIGCC IDE.) Il y a du nouveau dans le CVS, il faut que je refasse une release.

Emu-TIGCC ? C'est quoi ça encore ?
Je ne comprends plus rien avec tes forks... Avant c'était simple, on avait une IDE, et un ému, là j'ai l'impression que maintenant on a plusieurs versions et plusieurs noms pour des programmes identiques

Kevin Kofler (./149) :

* Dernière question sans doute HS : est-ce que la doc de TIGCC explique enfin clairement la manipulation de fichiers sur TI et fournit une explication autre que "t'as qu'à mieux comprendre la doc, c*nnard !" ?

Je trouve que la documentation est claire, si tu as des améliorations à proposer, j'attends tes patches.

"T'as qu'à mieux comprendre la doc, c*nnard !", donc. Okayyyyyyyy