kdewin foutage de geule - Page 8

Brunni (./210) :
A ce sujet, n'acceptez JAMAIS votre boss comme ami sur facebook...

huhu ^^

mais que pour l'instant
c'est moi qui développe en public

C'est bien, tu as compris

Mais toi, tu n'as pas l'air d'avoir compris ce que je voulais dire... Je suis pour un développement public et ouvert, avec tout le monde qui participe au même projet, et où l'ancienneté est respectée (c'est-à-dit que les nouveaux venus (*) ne peuvent pas imposer leurs idées avant d'avoir fait quoi que ce soit (**) à l'intérieur du projet). Malheureusement, ce n'est qu'un rêve, parce que vous refusez de collaborer.

(*) dans le contexte de TIGCC! Même si vous avez développé sur TI pendant des années, vous êtes des nouveaux en ce qui concerne TIGCC.

(**) Lionel, je suis au courant de tes contributions, donc tu as fait quelque chose, mais certainement pas assez pour être considéré un membre de l'équipe de plein droit. Je ne sais pas qui d'autre est dans ton projet parce que tu refuses de le révéler, mais je soupçonne que tu es le plus "ancien" parmi tout le groupe.

Tu refuses catégoriquement un certain nombre de souhaits que nous sommes plusieurs à porter, même si on les implémentait pour toi... et c'est nous qui refusons de collaborer ?

Que vient faire Fedora dans l'histoire ?

Kochise

mais je soupçonne que tu es le plus "ancien" parmi tout le groupe.

Le plus ancien dans la communauté TI-68k ? Non, même si je suis là depuis le printemps 2001 (sur yAronet depuis octobre 2001).

Kochise : Kevin cherche à trouver sa place dans un autre projet GPL (Fedora) alors qu'il ne semble pas du tout adhérer aux idées de liberté et de coopération sous-jacentes.

Le plus ancien dans la communauté TI-68k ?

Le plus "ancien" en termes de contributions à TIGCC (et dans ce contexte, ce n'est pas que la durée qui compte, mais aussi l'ampleur des contributions).

Thibaut (./217) :
Kevin cherche à trouver sa place dans un autre projet GPL (Fedora) alors qu'il ne semble pas du tout adhérer aux idées de liberté et de coopération sous sous-jacentes.

faut voir la tronche de la "communauté" TI aussi... Si tout le temps que certains perdent ici à se tapper dessus les uns les autres, ils le passaient à coder, on en serait à TIGCC 2.0 finale (que ce soit sans forker ou en forkant) depuis des années...

Après, certains des points dont parle Kevin... Bah, d'un côté, il est le seul à bosser sur ce projet, depuis un paquet d'années déjà... Ca te semble pas ne serait-ce qu'un peu compréhensible qu'il veuille pas que ça parte dans tous les sens ?
Et comparer à Fedora... heu... Sur TIGCC, il est tout seul ; sur Fedora, certainement pas ^^ rien que ça, ça joue...

Et il y a des points dont il parle avec lesquels je suis on ne peu plus d'accord (je pense notamment au principe de ne pas permettre à n'importe qui de faire n'importe quoi sur le SVN, et de faire des revues de code sur tout ce qui passe... même en entreprise, ça arrive, ça... et ça ne fait que du bien en terme de qualité, que ce soit qualité de code, ou qualité de logiciel)

D'accord, mais là c'est tout fork (indépendant ou pas) qu'il refuse. Pour lui, "fork" est un mot péjoratif. Je ne vois pas pourquoi. C'est l'essence même du libre.

Lionel Debroux (./214) :
Tu refuses catégoriquement un certain nombre de souhaits que nous sommes plusieurs à porter, même si on les implémentait pour toi... et c'est nous qui refusons de collaborer ?

Parce que vos souhaits n'apportent rien en pratique, par exemple:
* remettre le support pour VTI ne sert à rien parce que TiEmu fait tout ce que VTI faisait et plus,
* mettre les plans consécutifs sur HW1 ne sert à rien parce que les plans sont et ont toujours été 2 objets totalement indépendants (je ne vois pas pourquoi plan0+3840 devrait correspondre à autre chose qu'un buffer overflow, un plan est un tableau de 3840 octets, lire en dehors de ces 3840 octets est un débordement) et il est parfaitement possible d'en tenir compte dans les programmes (et ça a toujours été fait avant que Sasume a mal interprété la documentation (qui a été clarifiée depuis) lors du développement du TileMap Engine et que Sasume et toi avez rebaptisé ce bogue "fonctionnalité" et demandé que TIGCCLIB s'adapte à votre bogue, en refusant mon patch qui corrige ce bogue).

et ont de nombreux désavantages, par exemple:
* maintenance plus compliquée, une option inutile polluant les dialogues et le fait d'encourager l'utilisation d'un émulateur bogué et abandonné depuis des années dans le cas du support de VTI,
* gaspillage de 3840 octets de RAM sur HW1 (ou alors abandon de la compatibilité: les routines de gris copient LCD_MEM sur le plan foncé lors de GrayOn et l'inverse lors de GrayOff sur HW >=2 pour la compatibilité avec les programmes écrits pour HW1, donc on ne peut pas utiliser LCD_MEM comme sauvegarde de l'écran comme ça a été proposé) dans le cas des plans consécutifs. Il y a aussi le problème de l'évolutivité future: se fixer la contrainte que plan0+3840==plan1 réduit la flexibilité des modifications futures. Un exemple concret: il y a du travail pour les vérifications des bornes des tableaux dans GCC (pas encore supporté dans TIGCC), on pourrait éventuellement aussi envisager des vérifications dans un émulateur comme TiEmu avec l'aide des informations de débogage (ce qui éviterait le coût de la vérification en temps d'exécution on-calc). Si tu dépasses du plan0, une telle vérification des bornes relèverait un débordement, et elle aurait raison de le relever, parce que dans la plupart des cas, ce sera vraiment un bogue du programme. En établissant ça comme une manière valide d'accéder au plan1, vous empêchez la possibilité de détecter ce débordement.

Dans certains cas (plans consécutifs), il s'agirait aussi d'inverser une décision qui a été prise par toute l'équipe, y compris de grands noms comme Zeljko et Thomas.

La coopération n'implique pas accepter tout et n'importe quoi (essaie de mettre un lecteur MP3 ou un logiciel (hors firmware) non-libre dans Fedora, par exemple), il faut savoir accepter que certaines de ses idées soient rejetées et écouter les arguments pour un tel rejet. Et il faut accepter que les personnes qui sont impliquées dans un projet depuis longtemps et ont beaucoup contribué prennent les décisions, pas les personnes qui ont peu ou pas contribué (à ce projet particulier, pas à n'importe quoi), même s'il s'agit d'utilisateurs de longue durée. Dans le monde du libre, on appelle ça la méritocratie, presque tous les projets libres fonctionnent comme ça.

squale92 (./219) :
Et comparer à Fedora... heu... Sur TIGCC, il est tout seul ; sur Fedora, certainement pas ^^ rien que ça, ça joue...

Et surtout, moi j'accepte l'ancienneté des packagers qui ont travaillé sur KDE sous Fedora depuis plus longtemps que moi (Than Ngo et Rex Dieter), si je ne suis pas sûr pour une décision, je demande toujours l'avis à Than et/ou Rex.

Thibaut (./220) :
D'accord, mais là c'est tout fork (indépendant ou pas) qu'il refuse. Pour lui, "fork" est un mot péjoratif. Je ne vois pas pourquoi. C'est l'essence même du libre.

La possibilité de forker est une conséquence des libertés fournies, et elle peut être une garantie pour la survie du projet (par exemple si le projet d'origine est abandonné, voire rendu propriétaire si tout le code appartient à une seule personne ou entreprise). Mais si le projet d'origine est toujours actif, un fork représente un échec du système de développement communautaire (le fameux modèle de développement Open Source) (échec dû à des personnes qui n'ont pas pu se mettre d'accord pour travailler ensemble plutôt que l'une contre l'autre) et un gaspillage de ressources à dupliquer du travail (le fameux "syndrome NIH (Not Invented Here)").

Il t'appartient d'accepter les contributions des autres, plutôt que garder la paternité du projet par fierté. Ce sera tout à ton honneur je crois

Ce n'est pas par fierté que je garde la paternité du projet, mais par mérite. Si vous voulez pouvoir prendre des décisions, vous devrez vous intégrer graduellement au projet, en contribuant régulièrement, comme je l'ai fait moi-même, vous ne pouvez pas partir de zéro et demander le contrôle du projet du jour au lendemain (et ce même si vous êtes à plusieurs, ce n'est pas la loi du plus fort ici)!

Cf. par exemple http://www.apache.org/foundation/how-it-works.html#meritocracy. À noter que ce qui a fait que le modèle a fonctionné si bien est que "newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position", alors qu'ici les nouveaux refusent d'aider (et pourtant je leur propose sans arrêt de le faire), mais ils viennent tout de suite demander ma position dans le projet sans avoir fait quoi que ce soit pour le mériter. Je voudrais bien voir les nouveaux arrivés comme des "volunteers that wanted to help", le problème, c'est que leur attitude me prouve irréfutablement le contraire, et c'est pour ça que le système ne fonctionne pas.

Et je rajouterai aussi que si le projet a dégénéré au point de devenir de facto un projet individuel, c'est parce que personne (et je répète: personne) n'a fait le moindre effort pour rejoindre l'équipe quand nous n'étions plus que 2 (et Sebastian et moi avons demandé de l'aide à plusieurs reprises) et que s'il est resté en cet état dégénéré, c'est parce que personne (et je répète encore une fois: personne) ne m'est venu en l'aide pour les composants centraux de TIGCC depuis le départ de Sebastian, alors que je ne cesse de le demander. (Il y a eu des contributions ponctuelles à la documentation (nettoyage de la documentation déjà contribuée, notamment), mais sans l'engagement à long terme qui serait nécessaire vu la montagne de travail qui reste, et du travail effectué sur KTIGCC, mais pour le reste, j'ai été laissé essentiellement seul.)

Lionel, et apparemment d'autres membres de son équipe d'après ./216, présentent avec fierté leur ancienneté dans la communauté, mais ça implique aussi qu'ils ont déjà été présents à l'époque et ont refusé d'aider et que donc l'écroulement de l'équipe et la dégénération du projet est aussi de leur faute! Ce sont eux qui par leur inaction et leur paresse m'ont donné la responsabilité que j'ai actuellement, et qui maintenant refusent d'accepter les conséquences. C'est pour ça que je dis qu'ils ne veulent que le pouvoir de décision sans le moindre effort au sein du projet.

Je ne suis pas un dictateur, mais un développeur laissé seul par l'abandon de ses anciens coéquipiers et le refus de contribuer de la part de la communauté, y compris certaines des personnes qui réclament maintenant la direction du projet.

En même temps, demande-toi pourquoi personne n'a envie de travailler avec toi...

Tu es en train d'essayer d'invertir l'ordre des évènements là, les disputes sur certaines décisions que j'ai prises ne sont apparues que bien après que j'ai été laissé seul de la sorte, n'essaie pas de réécrire l'histoire pour inverser cause et effet.

L'attitude qui règne, c'est vraiment "je veux tout décider, mais avec le minimum d'effort de travail nécessaire (idéalement aucun)". Il est évident que ça ne peut pas marcher comme ça. Si par exemple Lionel avait contribué régulièrement à TIGCC, s'il avait par exemple mis à jour ses contributions à la documentation pour être directement mergeables et compilables sans modifications (notamment en corrigeant les cross-references) et effectué les tests nécessaires là où il a rajouté du code (par exemple les fameux "Address Hacks" - certains ne compilaient même pas!) et s'il les avait coupés en petits morceaux mergeables un à la fois (comme pour les patches au noyau Linux - comme Linus, moi aussi, j'attends des patches découpés en morceaux vérifiables et mergeables un à un) au lieu de nous dumper un gros pâté à découper (ce qui est non-trivial parce que les pages de documentation font référence à d'autres pages et que notre système de documentation a une tolérance zéro pour les références cassées: lien cassé = erreur fatale, la compilation s'arrête - et si vous venez vous plaindre de ça, je vous rappellerai que c'est moi qui veux refaire le système de documentation et Lionel qui veut bidouiller autour du système actuel), merger manuellement et tester (ce qui en tout (découper+merger+tester) nécessite des journées de travail), ou encore s'il avait fait autant d'améliorations dans le code que moi pendant toutes ces années, ou encore je ne sais pas (il y a beaucoup de manières de se rendre utile!), il aurait été reçu différemment (il serait probablement membre de l'équipe à l'heure actuelle et je discuterais avec lui pour les décisions à prendre). Mais il n'a rien fait de tout cela, alors que, pendant ce temps, moi je m'efforçais à nettoyer son gros dump de documentation (et me suis fait gueuler dessus régulièrement parce que je n'étais pas assez rapide pour lui, réaction qui a tout fait pour me démotiver au maximum, ce qui est une des raisons pour lesquelles le travail n'est toujours pas complété - c'est vraiment le comble, j'ai un travail immense qu'il ne veut pas faire et je me fais gueuler dessus par lui parce que je ne le fais soi-disant pas assez vite! ), je mettais à jour GCC régulièrement (notamment pour passer à GCC 4.0, puis 4.1), je codais KTIGCC et je corrigeais des bogues un peu partout.

pauvre petit il va nous faire pleurer la

Tu penses réellement que les exemples de divergences d'opinion que tu cites dans ./221, dont l'un ne figure d'ailleurs même pas explicitement dans la todo/wish list, sont les seuls ? Tu ne sais pas à quel point tu te plantes, on dirait


Toi qui écris souvent que tes études te prennent un temps fou... tu n'as pas imaginé que ça pouvait être la raison pour laquelle je n'ai pas contribué à TIGCC (ou à quoi que ce soit d'autre, d'ailleurs), et que je n'ai pas fait grand chose sur les programmes de TICT de H2 2004 à H1 2008, tout particulièrement de H2 2005 à H1 2008 ?
Ben oui. Sur cette période, j'étais occupé à une activité à plein temps qu'on appelle 'université'. Tu connais cette activité aussi, depuis plus longtemps que moi, et tu la poursuis encore. En 2004, je pensais encore toujours que tu processerais assez rapidement les contributions en attente (certaines depuis 2002). Je ne pouvais évidemment pas le faire moi-même, j'aurais été juge et partie.

Fast forward to 2008: ayant obtenu un Master, j'ai quitté l'activité à plein temps appellée 'université', pour une activité à plein temps appellée 'travail'. Une différence significative entre ces deux activités est que l'activité 'travail' n'a pas de travail à la maison (projets en groupe / etc.). Donc, j'ai plus de temps pour faire autre chose, par exemple sur des projets ouverts:
* citons une douzaine de patches à Wine fin 2007 (en plus de plusieurs bug reports de crashes de la suite de tests, maintenant corrigés par d'autres). Vérifie les announcements des releases de Wine de mi-août à décembre 2007 si ça te chante.
* le patch __ld_link_time_(timestamp|y|m|d) à ld-tigcc, que j'avais dit il y a des années que je ferais... j'ai tenu parole il y a environ trois mois. A moins que tu l'aies ajouté dans le CVS de TIGCC depuis mon `cvs up`(je n'utilise `cvssuck` que quand `cvs up` montre des changements, ce qui est rare) d'avant-hier, tu ne t'en es pas encore occupé, alors que ça ne représente pas une charge de travail phénoménale, le total faisant moins de 100 lignes. J'ai fait le changement que tu as demandé par rapport à la version précédente. Le patch a été testé par PpHd, après intégration du changement à flashos.a (que j'avais cherché en vain parce que ces #$&%\! de fichiers ne sont nulle part dans TIGCC ni dans sa doc - je n'ai pas bien compris pourquoi).
(Au passage: tu as pris le temps de participer avec nous à ce flame, donc c'est bien que tu as du temps quelque part... Moi, la raison pour laquelle je _peux_ passer ce temps - je ne dis pas que je n'aurais pas mieux à faire - est je suis actuellement en congés.)

Voilà pour la réponse au reproche "vous aviez qu'à m'aider auparavant", en ce qui me concerne. La période où tu as commencé à avoir vraiment besoin d'aide, pour la même raison que moi, correspond à celle où je ne pouvais pas. Je n'ai pas participé activement à tous les forums TI-68k sur une partie de cette période: j'ai arrêté définitivement TI-Gen, j'ai arrêté temporairement le forum de TIGCC/TICT, et je ne consultais pas toujours régulièrement yAronet.


Dire que ma doc représente un 'travail immense', c'est du foutage de gueule caractérisé, pour au moins deux raisons:
* tu as mon programme de tests complet, et ma doc additionnelle complète sur des ROM_CALLs non documentés, et tu es la seule personne à avoir ces deux infos.
* je t'ai fourni il y a au moins trois ans un sous-ensemble de fonctions plus faciles à reviewer/intégrer que les autres.


Quant à la méritocratie... Mon travail actuel porte sur l'implémentation C, nommée Cecilia, du projet Fractal ( http://fractal.objectweb.org ). J'ai la flemme de vérifier la licence de chaque morceau, mais il me semble que c'est un mélange LGPL/GPL.
Je n'avais utilisé Fractal (son implémentation Java nommée Julia, pour être précis) que passagèrement, à la fac, en 2006, mais je n'avais pas contribué au développement avant octobre 2007.
Depuis que je bosse sur Cecilia, j'ai fait des patches, des bug reports, des feature requests. Tu peux le vérifier avec le tracker de la Forge OW2, si tu ne me crois pas plus que tu ne sembles croire que le fork existe. J'ai corrigé des bugs (je n'ai pas pris la peine de mettre TOUS les bugs, y compris les few-liners, sur le tracker), implémenté plusieurs features (pas forcément réclamées par moi). Souvent en faisant reviewer par au moins un mainteneur de la toolchain, soit en privé, soit en public car je postais en général les séries de patches non triviaux sur le tracker de la Forge. Vérifie donc.
J'ai été consulté récemment [EDIT: par un mainteneur, au cas où ça ne serait pas clair] pour une question s'adressant explicitement aux mainteneurs de la toolchain. Il ne me paraît donc pas absolument déraisonnable de penser que je suis devenu *un* des mainteneurs de la toolchain. Même si je ne suis clairement pas au même niveau technique que les trois-quatre autres: contrairement à eux qui sont là depuis beaucoup plus longtemps, et qui l'ont créée, je ne maîtrise pas la toolchain dans son ensemble.

En résumé: mon boulot fonctionne par méritocratie, et il y a des preuves publiques du fait que je suis _capable_ de fonctionner comme ça.
Alors, pourquoi ne veux-je donc, maintenant que j'ai plus de temps, pas travailler qu'avec toi pour faire quelque chose sur TIGCC ? Il y a des éléments de réponse dans ce topic, il y en a dans d'autres.



Tiens, au fait, une question que tu n'as pas posée, et à laquelle je vais répondre: puisque c'est moi qui veux tant que ça ce fork (c'est moi que tu vises dans tes messages)... pourquoi _maintenant_ et pas il y a six mois, ou plus ? Après tout, il y a six mois, je travaillais déjà. Et avant de commencer mon travail, j'étais à plein temps en entreprise en stage de fin d'études - sans travail obligatoire à la maison le soir et le week-end (même s'il m'est arrivé de bosser pour la boîte).
La réponse est, là aussi, simple. Depuis un peu plus de trois mois, tu nous as envoyé tout un tas de signaux pour la maintenance et l'évolution de TIGCC, que nous sommes plusieurs à trouver inquiétants:
* tentative d'obstruction à la création d'un _miroir_ Git, par le refus de créer la ML des commits pour voir quand il y a des changements qui nécessitent le déclenchement de la force brute `cvssuck` avec encore moins de charge pour le serveur qu'en tournant `cvs up`. J'ai tenu ma parole, ce miroir Git reste un miroir. Et je ne vais pas te dire si ce miroir sert à quelque chose dans le fork.
* tout récemment, la mention de la possibilité de suppression d'A68k, sans avoir ajouté un mode de compatibilité avec la syntaxe A68k à gas. Obstacle à la création d'un OS _libre_ pour TI-68k.
* refus de l'ajout d'un patch de PpHd à ld-tigcc, sous prétexte qu'il est incomplet pour certains autres usages (existaient-ils déjà en pratique, ces usages ?). J'ai lu la discussion en diagonale, mais le fait est que TIGCC upstream ne permet plus de compiler PedroM, le principal OS _libre_ pour TI-68k. C'est à ce moment-là qu'a commencé, dans les faits, le fork. Quel choix PpHd avait-il ?
* persistance du refus d'intégrer tout ou partie des features de PreOS/PedroM dans TIGCC ( topics/112598-export-de-version ), alors que PreOS est le kernel devenu standard depuis 'juste' quatre ou cinq ans. Même si le mode de programmation kernel-based a objectivement des défauts, il a objectivement des avantages, et rendre plus difficile pour les utilisateurs potentiels d'en profiter n'est pas une façon de créer le meilleur outil pour tous.

Enough is enough.
Les trois derniers éléments ci-dessus sont postérieurs à mes patches à ld-tigcc. A l'époque, *je* n'avais pas encore le projet de créer _activement_ un fork - même si, évidemment, en créant le miroir Git, j'espérais que ça finisse par arriver. Tu as joué contre ton camp en refusant la simple création de la ML, c'est clair, d'autant plus qu'il est trivial de contourner ce refus.
Sur ces deux derniers éléments, même si on t'envoyait les patches tout prêts et parfaits, tu ne les intégrerais pas...

Kevin Kofler (./227) :
Tu es en train d'essayer d'invertir l'ordre des évènements là, les disputes sur certaines décisions que j'ai prises ne sont apparues que bien après que j'ai été laissé seul de la sorte, n'essaie pas de réécrire l'histoire pour inverser cause et effet.

Ah mais ça fait bien longtemps que beaucoup de gens se sont rendus compte à quel point tu étais capricieux et que ça serait un enfer de bosser avec toi

Tu es en train d'essayer d'invertir l'ordre des évènements là, les disputes sur certaines décisions que j'ai prises ne sont apparues que bien après que j'ai été laissé seul de la sorte, n'essaie pas de réécrire l'histoire pour inverser cause et effet.

Ah mais ça fait bien longtemps que beaucoup de gens se sont rendus compte à quel point tu étais capricieux et que ça serait un enfer de bosser avec toi

+1 Flanker, évidemment.

Lionel Debroux (./229) :
Tu penses réellement que les exemples de divergences d'opinion que tu cites dans ./221, dont l'un ne figure d'ailleurs même pas explicitement dans la todo/wish list, sont les seuls ?

Non, mais ce sont les 2 exemples qui me sont venus à l'esprit et ils sont suffisants pour expliquer quelles peuvent être les raisons pour lesquelles un patch ou une idée de patch n'est pas accepté(e). (Raisons que je pense d'ailleurs déjà avoir soulevées à l'époque, sauf peut-être pour l'argument de la détection des débordements.)

Pas le temps de répondre au reste maintenant, ce sera fait plus tard.

Kevin Kofler (./222) :
Mais si le projet d'origine est toujours actif, un fork représente un échec du système de développement communautaire

provoqué par qui?

Kevin Kofler (./224) :
Ce n'est pas par fierté que je garde la paternité du projet, mais par mérite.

c'est pas un peu la même chose?

Kevin Kofler (./224) :
vous devrez vous intégrer graduellement au projet, en contribuant régulièrement

on ne peut pas contribuer efficacement en utilisant CVS quand on n'est plus d'un seul développeur; il y a trop de risques.

Kevin Kofler (./225) :
Je ne suis pas un dictateur, mais un développeur laissé seul par l'abandon de ses anciens coéquipiers et le refus de contribuer de la part de la communauté, y compris certaines des personnes qui réclament maintenant la direction du projet.

on va pleurer. Vu comment tu refuses les contributions qui te paraissent inutiles, alors que si elles ont été contribuées, c'est qu'elles servent à quelqu'un, ça donne pas super envie.

Et puis je sais pas ou t'as vu que certaines personnes voulaient te "piquer la direction du projet" (bwhahaha, on dirait un grand patron), personne nie ton pouvouââââr, juste ton jugement un peu sec et rapide des contributions qui te plaisent pas.

d'ou l'intéret d'un fork, pour intégrer des contributions voulues mais refusées.

vous devrez vous intégrer graduellement au projet, en contribuant régulièrement

on ne peut pas contribuer efficacement en utilisant CVS quand on n'est plus d'un seul développeur; il y a trop de risques.

Il a écrit plus tôt dans la discussion qu'il n'y aurait (au début) qu'un seul développeur (lui), à qui les autres enverraient des patches faits avec diff
Comme actuellement.
CVS est peu adapté au maintien de séries de patches, pourtant...

on va pleurer. Vu comment tu refuses les contributions qui te paraissent inutiles, alors que si elles ont été contribuées, c'est qu'elles servent à quelqu'un, ça donne pas super envie.

Et puis je sais pas ou t'as vu que certaines personnes voulaient te "piquer la direction du projet" (bwhahaha, on dirait un grand patron), personne nie ton pouvouââââr, juste ton jugement un peu sec et rapide des contributions qui te plaisent pas.
d'ou l'intéret d'un fork, pour intégrer des contributions voulues mais refusées.

Très gros crayon.
J'ajouterai que c'est certainement mieux que ce que j'ai écrit, parce que beaucoup plus concis

Kevin, qu'est-ce que ça peut te faire que des personnes développent un fork à partir de TIGCC ? Laisse donc les gens adapter les outils à leurs envies. Manifestement TIGCC (et l'IDE actuel) a été développé de façon à faciliter certaines choses (1 projet = 1 compilation, etc. - tout ce qui a été énoncé plus haut). D'autre personnes aimeraient agrémenter les caractéristiques de TIGCC, mais celles-ci n'iraient probablement pas dans le sens que tu aimerais. Cela pose-t-il un problème ? Si tu n'acceptes pas certaines contributions (ou si tu ne fais aucun effort pour aller dans certaines directions), pourquoi ne pas laisser les autres faire leur cuisine, de leur côté ?

Brunni (./201) :

dualmoo (./199) :
Les droits moraux sont incessibles, imprescriptibles et inaliénables.

Intéressant J'ai l'habitude aussi de mettre en DP, mais je savais pas que c'était pas possible.
Qu'est-ce qu'il se passe alors, est-ce que tu as des infos sur les droits qui "restent" une fois que tu as déclaré ton programme comme étant du DP?

Je n'en suis malheureusement pas sûr : le droit d'auteur est très complexe, et il y a tout un tas d'exceptions, notamment dans le cas des logiciels. Néanmoins je suis sûr que même si l'auteur essaye d'être le plus permissif possible avec son œuvre, il lui restera toujours des droits dessus.

dualmoo (./236) :

Brunni (./201) :

dualmoo (./199) :
Les droits moraux sont incessibles, imprescriptibles et inaliénables.

Intéressant J'ai l'habitude aussi de mettre en DP, mais je savais pas que c'était pas possible.
Qu'est-ce qu'il se passe alors, est-ce que tu as des infos sur les droits qui "restent" une fois que tu as déclaré ton programme comme étant du DP?

Je n'en suis malheureusement pas sûr : le droit d'auteur est très complexe, et il y a tout un tas d'exceptions, notamment dans le cas des logiciels. Néanmoins je suis sûr que même si l'auteur essaye d'être le plus permissif possible avec son Å“uvre, il lui restera toujours des droits dessus.

Ca englobe droit de retrait, droit de mention du nom, et le droit patrimonial (et, normalement, l'Europe s'est alignée sur la France à ce niveau).

Oui mais comme je l'ai dit, il y a des exceptions selon le type d'œuvre.

Lionel Debroux (./229) :
Toi qui écris souvent que tes études te prennent un temps fou... tu n'as pas imaginé que ça pouvait être la raison pour laquelle je n'ai pas contribué à TIGCC (ou à quoi que ce soit d'autre, d'ailleurs), et que je n'ai pas fait grand chose sur les programmes de TICT de H2 2004 à H1 2008, tout particulièrement de H2 2005 à H1 2008 ?

Mais ça ne justifie pas que depuis ton retour, tu attends te retrouver en des positions comme si tu avais travaillé sur TIGCC pendant tout ce temps! Autant, si tu avais intégré l'équipe à l'époque, je ne verrais pas de problème de te rendre ta position de l'époque, autant là le problème est que ta position de l'époque, c'est "rien". Moi aussi, j'ai fait mes études, mais ça ne m'a pas empêché de travailler sur TIGCC pendant des années. Là, ce qui me déborde, c'est études + travail (projet payé à l'université) + Fedora (comaintenance de KDE).

En 2004, je pensais encore toujours que tu processerais assez rapidement les contributions en attente (certaines depuis 2002). Je ne pouvais évidemment pas le faire moi-même, j'aurais été juge et partie.

Tu aurais pu faire un grand nombre de trucs qui auraient facilité l'intégration, cf. ./227, et je t'avais bien signalé ça à l'époque. Tu avais répondu que tu avais fait à ton avis assez de travail là-dessus et que c'était as is.

* le patch __ld_link_time_(timestamp|y|m|d) à ld-tigcc, que j'avais dit il y a des années que je ferais... j'ai tenu parole il y a environ trois mois. A moins que tu l'aies ajouté dans le CVS de TIGCC depuis mon `cvs up`(je n'utilise `cvssuck` que quand `cvs up` montre des changements, ce qui est rare) d'avant-hier, tu ne t'en es pas encore occupé, alors que ça ne représente pas une charge de travail phénoménale, le total faisant moins de 100 lignes. J'ai fait le changement que tu as demandé par rapport à la version précédente. Le patch a été testé par PpHd, après intégration du changement à flashos.a (que j'avais cherché en vain parce que ces #$&%\! de fichiers ne sont nulle part dans TIGCC ni dans sa doc - je n'ai pas bien compris pourquoi).

Je ne vois pas ce que ça change si le patch est mergé dans le CVS un mois plus tôt ou plus tard parce qu'il n'y a de toute façon eu aucune release depuis et que pas grand monde n'utilise TIGCC HEAD. Mais je peux merger ça ce weekend si ça te fait plaisir.

Dire que ma doc représente un 'travail immense', c'est du foutage de gueule caractérisé, pour au moins deux raisons:* tu as mon programme de tests complet, et ma doc additionnelle complète sur des ROM_CALLs non documentés, et tu es la seule personne à avoir ces deux infos.

Ton programme de tests ne peut pas être complet vu qu'il y a des contributions qui ne compilaient même pas (et je parle bien de code là, pas de doc, dans laquelle carrément tout ne se merge pas sans conflits ou ne compile pas, à cause des cross-references).

* je t'ai fourni il y a au moins trois ans un sous-ensemble de fonctions plus faciles à reviewer/intégrer que les autres.

Des fonctions que tu retenais "plus faciles à reviewer/intégrer que les autres", mais qui ne l'étaient pas, il y avait exactement les mêmes problèmes que pour les autres. Et on était loin des morceaux intégrables l'un après l'autre sans casser la compilation des docs que je demandais (et demande toujours, et demanderai aussi pour toute future contribution aux docs).

Quant à la méritocratie... Mon travail actuel porte sur l'implémentation C, nommée Cecilia, du projet Fractal ( http://fractal.objectweb.org ). J'ai la flemme de vérifier la licence de chaque morceau, mais il me semble que c'est un mélange LGPL/GPL.

Je m'en fous des autres projets auxquels tu participes, ce qui compte ici, c'est ton mérite dans le cadre de TIGCC.

En résumé: mon boulot fonctionne par méritocratie, et il y a des preuves publiques du fait que je suis _capable_ de fonctionner comme ça.Alors, pourquoi ne veux-je donc, maintenant que j'ai plus de temps, pas travailler qu'avec toi pour faire quelque chose sur TIGCC ? Il y a des éléments de réponse dans ce topic, il y en a dans d'autres.

Bref, tu ne respectes la méritocratie que quand ça t'arrange.

Tiens, au fait, une question que tu n'as pas posée, et à laquelle je vais répondre: puisque c'est moi qui veux tant que ça ce fork (c'est moi que tu vises dans tes messages)...

Je te vise parce que je ne sais pas qui d'autre participe, tu as refusé de le révéler.

* tentative d'obstruction à la création d'un _miroir_ Git, par le refus de créer la ML des commits pour voir quand il y a des changements qui nécessitent le déclenchement de la force brute `cvssuck` avec encore moins de charge pour le serveur qu'en tournant `cvs up`. J'ai tenu ma parole, ce miroir Git reste un miroir. Et je ne vais pas te dire si ce miroir sert à quelque chose dans le fork.

Il te sert forcément, sinon pourquoi le maintiendrais-tu, surtout étant donné que j'ai dit qu'il ne me servait à rien pour mon travail.

* tout récemment, la mention de la possibilité de suppression d'A68k, sans avoir ajouté un mode de compatibilité avec la syntaxe A68k à gas. Obstacle à la création d'un OS _libre_ pour TI-68k.

Un logiciel n'est vraiment libre que s'il est compilable avec des outils libres, cf. http://www.gnu.org/philosophy/java-trap.html (l'exemple n'est plus d'actualité, le problème l'est). PedroM doit être porté vers GNU as (enfin, il aurait dû être codé avec GNU as dès le départ, mais le mal a été fait, maintenant il faut y remédier, c'est-à-dire porter). Si PpHd continue à refuser de le faire, je vais finir par le faire.

* refus de l'ajout d'un patch de PpHd à ld-tigcc, sous prétexte qu'il est incomplet pour certains autres usages (existaient-ils déjà en pratique, ces usages ?).

Pas "sous prétexte", il l'est. Et PedroM lui-même est un de ces usages, il ne sera pas optimisé autant que possible à cause des limitations techniques de l'optimisation linker implémentée.

J'ai lu la discussion en diagonale, mais le fait est que TIGCC upstream ne permet plus de compiler PedroM, le principal OS _libre_ pour TI-68k. C'est à ce moment-là qu'a commencé, dans les faits, le fork. Quel choix PpHd avait-il ?

Le choix de faire un patch complet (et oui, ça implique de patcher aussi les 2 assembleurs, ou alors de patcher GNU as et laisser tomber A68k, pour une meilleure implémentation des relogements optimisables et non-optimisables).

Enfin bon, si c'est un vrai problème, je veux bien sortir un ld-tigcc-experimental non officiel pour pouvoir compiler PedroM, mais je ne peux pas intégrer le patch fait à moitié au ld-tigcc officiel (d'autant plus que je veux enfin avoir une 0.96 stable pour pouvoir arrêter le bordel des bêtas).

Le problème avec les contributions de PpHd est qu'il ne fait que le strict minimum pour que le patch marche pour lui, même si ça ne marche pas pour les autres. Et je n'ai jamais vu de documentation au format correct non plus. (Il m'a envoyé un stdint.h à un moment, mais c'était un header seul qui n'utilisait pas du tout le générateur de headers et documentation fait pour et qui par conséquent n'avait aucune documentation. Inutile de dire que ce patch n'a pas été mergé (et je le lui ai expliqué, il a répondu que ce serait trop de travail et exigé que je prenne le header tel quel, ce que j'ai évidemment refusé). Tout identifiant (fonction, variable, type, macro) dans TIGCCLIB doit avoir un fichier .hsf correspondant, sauf si l'identifiant est totalement interne et pas prévu pour être utilisé directement. De même, toute option de ld-tigcc doit être documentée dans les fichiers .hss de ld-tigcc (mais dans ce cas c'est un seul fichier pour tous les arguments).)

* persistance du refus d'intégrer tout ou partie des features de PreOS/PedroM dans TIGCC ( topics/112598-export-de-version ), alors que PreOS est le kernel devenu standard depuis 'juste' quatre ou cinq ans. Même si le mode de programmation kernel-based a objectivement des défauts, il a objectivement des avantages, et rendre plus difficile pour les utilisateurs potentiels d'en profiter n'est pas une façon de créer le meilleur outil pour tous.

Et si on lance le programme avec certains anciens kernels, il plante la calculatrice! C'est totalement inacceptable. Si PpHd nous proposait une manière de détecter si on a un kernel suffisamment récent (sans devoir coder en dur les identifiants PO (PreOs) et RO (PedroM), ce serait un lock-in, ça!), je pourrais envisager de rajouter des fonctionnalités comme ça (dans un preos.h, certainement pas dans compat.h qui doit contenir des fonctions/macros compatibles!). Mais le nouveau format que PpHd a proposé (qui proposait d'ailleurs aussi la seule innovation vraiment intéressante: les relogements compressés - on les a déjà en _nostub avec code de démarrage d'ailleurs ) a été annulé sans remplacement.

Tu as joué contre ton camp en refusant la simple création de la ML, c'est clair

N'importe quoi, tu aurais très certainement trouvé une autre excuse sinon. Et il est clair que ton miroir ne sert qu'à développer votre fork, cf. la réponse à ce sujet plus haut.

d'autant plus qu'il est trivial de contourner ce refus.

Si je désactive le CVS, tu contourneras ça comment? Voire si j'y committe n'importe quoi sans te prévenir et que je release une branche privée totalement différente. Et avec le temps que j'ai passé à maintenir mon patchset pour GCC, je sais aussi exactement quoi faire de release à release pour transformer tes merges en enfer (le projet GCC a fait plein de trucs comme ça sans faire exprès).

Sur ces deux derniers éléments, même si on t'envoyait les patches tout prêts et parfaits, tu ne les intégrerais pas...

Pour la section de variables globales dans le FlashOS, évidemment que j'intègrerai (sans 's' parce qu'à mon avis, ce patch finira bien par exister!) un patch parfait, c'est bien pour ça que j'en demande un! Dans le cas des fonctionnalités PreOs-only, pour que le patch soit parfait, il faut d'abord que la présence d'un kernel acceptable soit détectable, sinon le programme plante la calculatrice si on le lance avec un ancien kernel et je ne veux pas qu'on puisse compiler des programmes qui plantent la calculatrice sans que le programme soit bogué avec TIGCC.

Heu on revient au sujet et vous voyez ca en MP