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

Tu t'es jeté tout seul par ton comportement, nuance. Flanker a bien compris ce que j'ai écrit, lui.
A moins que tu présentes des excuses complètes, assorties de la promesse définitive de travailler avec moi en tenant compte de ce que la communauté veut, je ne vois pas comment JB te réintégrerait. Et encore, ça ne serait peut-être même pas suffisant, vu tu as dénigré personnellement roms et lui.


Ne pourrait-on pas avancer sur le renommage de TIEmu-fork ?

Emu4TI ?

L'histoire des noms sera discutée entre Tyler et moi, les noms que nous choisirons ne vous regardent pas.

Il faudra bien le rendre public un jour...

Kevin Kofler (./63) :
L'histoire des noms sera discutée entre Tyler et moi, les noms que nous choisirons ne vous regardent pas.

Et ton absence de politesse ? Il ne nous regarde pas non plus ?

Kevin, vu la façon dont tu nous as fait chier parce qu'on n'a pas officialisé dès la première minute ce qui s'appelle maintenant GCC4TI, il serait de TRES bon ton de rendre _rapidement_ officiel ton fork

Lionel Debroux (./66) :
Kevin, vu la façon dont tu nous as fait chier parce qu'on n'a pas ouvert dès la première minute ce qui s'appelle maintenant GCC4TI, il serait de TRES bon ton de rendre rapidement public ton fork

Attends, tu n'espères quand même pas qu'il applique à lui-même ses propres principes ?

C'est bien pour ça que je les lui rappelle
Je suis gentil: je le fais le jour même, alors que j'aurais pu attendre.

Il devrait déjà apprendre le savoir-vivre élémentaire, ça lui serait sûrement plus utile si jamais il sort de chez lui...

J'ai déjà rendu public le déplacement du développement ailleurs, c'est vous qui me faites ch**r pour que je change les noms de la version officielle parce que vous refusez de renommer votre fork.

notre fork ? de quoi ? TiLP? TiEMU ? il me semble qu'un projet lié a un nom de domaine, a la priorité sur le nom, et semble ne pas pouvoir etre un fork

Et pour rapel :

Domain Name:TILP.INFO
Created On:21-Jan-2002 08:56:26 UTC


Domain Name:CALCFORGE.ORG
Created On:06-Dec-2005 19:15:47 UTC


Je crois que TiLP.info est et restera l'original, et celui de calcforge sera le fork

Kevin Kofler (./70) :
J'ai déjà rendu public le déplacement du développement ailleurs, c'est vous qui me faites ch**r pour que je change les noms de la version officielle parce que vous refusez de renommer votre fork.

et le respect, dans tout ça ?

(ça donne envie de me déclarer mainteneur officiel de TIGCC, tiens )

Et ta légitimation, ce serait? La mienne, tu la connais.

Mais de toute façon, on va changer les noms parce que je n'ai pas envie de me battre pour une histoire tellement ridicule.

Kevin Kofler (./73) :
Et ta légitimation, ce serait? La mienne, tu la connais.

Y a besoin d'une ?

Oui.

En tout cas, je suis en train d'écrire un mail à Tyler pour proposer de nouveaux noms, j'attendrai sa réponse.

Tiens, ça me fait penser qu'il n'y a pas que dans TILP et TIEmu que Kevin témoigne de l'irrespect à Romain, d'ailleurs...
Il y a un petit moment, Kevin a viré Romain (qui était dans tigcc-linux avant lui) comme un malpropre de TIGCC, parce que Romain a fait une erreur dans la manipulation de cet outil à chier qu'est CVS. Je ne suis plus sûr de ce que c'était, mais ce que je sais, c'est que c'était une erreur qu'il est TRES difficile de faire avec SVN ou n'importe quel vrai SCM utilisable pour faire du boulot sérieux.

La seule fois que j'ai essayé d'utiliser des branches et des tags avec CVS, c'était il y a presque trois ans et demi, pour un projet pendant mes études. Les profs faisaient du support sur l'utilisation de CVS (le reste, c'était à nous de nous démerder). Au bout de très peu de temps, on a réussi à committer, nous aussi, des choses sur la mauvaise branch, et c'était un cauchemar pour annuler. En bossant à plusieurs, on a rencontré un commit non atomique ET un checkout partiel.
=> on a abandonné l'utilisation d'un SCM pour le reste du projet, et je n'ai plus jamais utilisé CVS pour committer quoi que ce soit.
Je comprends donc tout à fait que Romain ait pu faire une erreur de manipulation avec CVS...


Enfin bon, ce n'est pas une nouveauté qu'avec Kevin, TIGCC n'est pas du boulot sérieux... Dernier exemple en date: je me suis rendu compte hier, en debuggant un bug du générateur de code (partie GCC du TIGCC patch), que ça fait presque 4 ans qu'un des exemples ne compile pas. Ca veut dire que Kevin n'a même pas dû utiliser les exemples en tant que tests de non-régression pour les diverses versions de GCC sorties depuis la date de ce commit...

Son erreur était un commit à partir d'une copie locale salie (parce qu'il a compilé un paquetage Debian qui applique des patches directement dans son checkout la vraie erreur est là, les exports n'existent pas sans raison) sans vérifier ce qu'il est en train de committer, ça se serait passé exactement pareil avec SVN, voire avec git si on utilise git -a. De plus, il n'y avait pas de raison qu'il travaille directement dans le CVS du tout plutôt que d'utiliser le tarball et un .diff.gz Debian comme tout le monde (sauf les projets pour lesquels Debian est upstream, ce qui n'est clairement pas le cas de TIGCC), je lui avais déjà dit au moins 2 fois de ne pas le faire (parce que je ne veux pas attendre qu'il mette à jour son répertoire debian avant de faire une release, normalement on release d'abord et on package après, j'ai d'ailleurs déplacé tous mes specfiles RPM vers svn.calcforge.org il y a 4 mois pour la même raison) et il a continué à polluer mon dépôt avec ses répertoires debian.

Kevin Kofler (./51) :
Bon bah, je vais en parler à Tyler de l'histoire des noms, on peut peut-être trouver une solution qui satisfait tout le monde. Parce que c'est clair que s'il y a 2 projets qui revendiquent le même nom, ça va être le bordel (cf. RPM avec rpm.org et rpm5.org).

genre ce sera pas de ta faute

sinon pour mémoire:

Kevin Kofler (./58) :

Lionel Debroux (./55) :
tentative de coup d'état.

Voilà une manière intéressante d'inverser les choses. C'est qui qui commet le coup d'état ici? Tu n'étais même pas un committeur jusqu'à il y a quelques jours.

Kevin Kofler (./3) :
En tant que seul membre actif restant, je me déclare mainteneur officiel de TiLP, TiEmu, GFM et les tilibs. Toute personne voulant continuer le développement est priée de me contacter. Pour l'instant, les dépôts restent sur svn.tilp.info, mais ils pourraient être déplacés ailleurs si des raisons techniques ou administratives le nécessitent.

y'a bien qu'un seul Kevin Kofler qui poste hmm? je me trompe pas...

Hmm, y a-t-il des liens qui expliquent pourquoi ce n'est pas bien de mettre des metadata pour les systèmes de packaging dans les repositories ?
Parce que à part compliquer légèrement le script de build du package (ne suffit-il pas de ne pas mettre, d'une façon ou d'une autre, les metadata des autres systèmes de packaging ?), je ne vois pas trop.

./78: Kevin accuse, encore une fois, et encore une fois à tort, les autres de faire ce qu'il fait lui-même. Une nouvelle occurrence dans une déjà longue série lamentable, qu'il n'a pas l'air de vouloir arrêter...

ne perds pas de temps

Kevin > tu ne te demandes pas pourquoi à chaque fois que tu participes à un projet, les autres décident d'arrêter ?

Petite projection dans l'avenir : tu participes à tous les projets, et tu te retrouves tout seul dans la communauté... C'est vraiment ce que tu cherches ? Tu veux réussir la prouesse de réussir à flinguer la plus grande communauté possible ?
Et comme tu as déjà fait tes armes avec la communauté TI (et oui, si elle est morte, c'est en bonne partie grâce à toi), tu t'attaques à la communauté Fedora ? Perso, ça ne me dérange pas plus que ça (ràf de Fedora), mais je sens que tu auras un peu plus de mal

Lionel Debroux (./79) :
./78: Kevin accuse, encore une fois, et encore une fois à tort, les autres de faire ce qu'il fait lui-même. Une nouvelle occurrence dans une déjà longue série lamentable, qu'il n'a pas l'air de vouloir arrêter...

Bah que veux-tu, il n'a pas de vie, alors faut bien qu'il pourrisse celle des autres, ça l'occupe ^^

Lionel Debroux (./79) :
Hmm, y a-t-il des liens qui expliquent pourquoi ce n'est pas bien de mettre des metadata pour les systèmes de packaging dans les repositories ?

Parce que normalement le logiciel est d'abord releasé puis packagé, donc la release se trouve avec des métadonnées pour la release précédente. C'est exactement ce qui s'est passé pour les specfiles des projets LPG, c'est pour ça que je les ai déplacés ailleurs (repo-specfiles sur svn.calcforge.org, ça existait déjà bien avant que les projets eux-mêmes aient été déplacés là).

Et sinon, Tyler et moi sommes d'accord pour les nouveaux noms (juste 2 ou 3 détails à discuter), donc les changements de nom pourraient avoir lieu dès ce soir (si Tyler est en ligne).

t'es vraiment une sacré tête de mule.

Parce que normalement le logiciel est d'abord releasé puis packagé, donc la release se trouve avec des métadonnées pour la release précédente.

Qu'est-ce qui interdit de faire les deux en même temps, à savoir ne committer une release ET ses méta-données ensemble, avec le numéro de version et les autres méta-données à jour, que si on a vérifié que la release peut être packagée ?
Bien sûr, il faut synchroniser les working copies des packagers, mais il y a des solutions techniques appropriées qui fonctionnent très bien.

Dans un autre type de systèmes de packaging: maven-release-plugin automatise la création d'une release. Avec SVN, une release prend en général trois commits, qu'elle foire ou qu'elle réussisse.
Avec un DSCM qui gère les tags de façon plus intelligente que SVN (ou pire, CVS) et qui ne pushe pas les commits tant que le packaging merde, on pourrait réduire cela à 2 commits + 1 tag (une simple étiquette).

Lionel Debroux (./84) :
Qu'est-ce qui interdit de faire les deux en même temps, à savoir ne committer une release ET ses méta-données ensemble, avec le numéro de version et les autres méta-données à jour, que si on a vérifié que la release peut être packagée ?

Que c'est moi qui release et Romain qui faisait les paquetages Debian (et l'inverse pour les specfiles Fedora des logiciels LPG), donc c'était toujours un problème de coordination et au final ça n'a jamais fonctionné.

De plus, ce n'est pas la manière de fonctionner habituelle du packaging. Normalement, on utilise un tarball ("pristine tarballs") et on le package (on rajoute un .spec et des patches pour Fedora, un .diff.gz qui contient l'équivalent de tout ça sous Debian).

Dans un autre type de systèmes de packaging: maven-release-plugin automatise la création d'une release.

Les specfiles autogénérés ne sont pratiquement jamais conformes aux règles de Fedora (et celles de Debian sont au moins aussi strictes), ce n'est pas une solution envisageable.

Dans un autre type de systèmes de packaging: maven-release-plugin automatise la création d'une release.

Les specfiles autogénérés ne sont pratiquement jamais conformes aux règles de Fedora (et celles de Debian sont au moins aussi strictes), ce n'est pas une solution envisageable.

Clairement
Ma mention de Maven n'était pas une suggestion de solution (je ne suis pas un grand fan du XML très verbose de Maven...), c'était une information sur une autre façon de faire utilisée dans un autre contexte

Les nouveaux noms des logiciels CalcForge (anciennement logiciels LPG) ont été décidés:
[ul][li]Les tilibs seront désormais connus comme CalcForge libs:[/li][ul][li]libticables(2) → libcalccables[/li][li]libticalcs(2) → libcalcprotocols[/li][li]libticonv → libcalcconv[/li][li]libtifiles(2) → libcalcfiles[/li][/ul][li]TiLP → CalcForgeLP[/li][li]GFM → CalcForgeLP GFM[/li][li]tfdocgen → CalcForge docgen[/li][/ul]Ces noms ne mentionnent volontairement pas "TI" parce que nous serons ouverts à un éventuel support des calculatrices HP et Casio dans les mêmes libs (surtout en vue du flop qu'est la série TI Nspire, et aussi parce que la Nspire a de toute façon nécessité une généralisation des libs, étant très différente des autres modèles).

Quant à TiEmu, son nouveau nom sera Emu-TIGCC, reflétant ainsi sa place dans la chaîne d'outils de TIGCC. L'éditeur de skins s'appellera Emu-TIGCC SkinEdit.

TilEm (non-libre) et les tidrivers (obsolètes) ne seront pas maintenus sur svn.calcforge.org. (Pour TilEm, il y aura juste, dans le dépôt repo-specfiles, le specfile et un patch pour compiler avec libcalccables à la place de libticables2.)

Les modifications seront effectuées dans le SVN bientôt.

Les dossiers ont été renommés dans le SVN. http://svn.calcforge.org/viewvc/
Renommer les logiciels dans le code lui-même prendra plus de temps, ce sera fait aussitôt que possible, et dans tous les cas avant la première release.

Que "TIGCC" soit mentionné dans le nom de TIEmu-fork a tout à fait du sens pour un projet créé dans le but d'être contrôlé de la même manière que TIGCC...

Ce n'est pas un fork, c'est juste le projet officiel qui change de nom pour refléter l'intégration avec TIGCC (ou pour les CalcForge libs et CalcForgeLP, pour une possible ouverture aux autres marques de calculatrices).