Open the SVN ? - Page 1

I need to understand the deep arguments for and against the opening of the SVN...
I'm for opening the fork. If Kevin Kofler does anything bad he could be banned, no ?

There's no question that the fork will be opened
On the one hand, I'm unconvinced there's much case for posting the URLs of the fork (SVN, Trac, ML, forum) public, as long as we have only changes that are invisible to a wide majority of users, which is the current state of the fork.
On the other hand, as much as I hate us having to give in to Kevin's pressure, I think we'd better make the fork public before he closes the TIGCC CVS repository. That way, it will be harder for him to make us look bad for not working openly for a while (even if we have valid reasons not to "commit early, release often", IMO).
Note that if we want people to actually use the fork, there's no way we can ask them to compile the fork themselves: we'd have to spend the time to make a release (recompiling the binaries that need to be recompiled, etc.). It probably wouldn't be THAT long, and it would be less of a problem for us than it seems to be for Kevin, because we have more manpower, more Windows and Linux versions to compile and test on, though...

What do others think ?

If Kevin sabotages our infrastructure, he should indeed be banned. With no round of "next time you behave such a way, you'll be banned", because he knows it very well that that this kind of behaviour is unacceptable.
Wikis and SCM can be reverted to previous versions, so if he was stupid enough to wreck havoc, things could be straightened out quickly. But I think we'd be pretty foolish to give him write access to the SVN, after he threatened in topics/113677-kdewin-foutage-de-geule of introducing subtle bugs in upstream TIGCC so that the fork (which is sooooo eager to take up his own commits while not giving anything back, as he has written in topics/113677-kdewin-foutage-de-geule and topics/2-114905-tigcc-contributions-fork ) has bugs...

That said:
* Kevin talks much more than he actually acts (remember him threatening multiple times of poisoning in TIGCC's GCC the identifiers used by ExtGraph itself or its modified grayscale routine ?);
* I think he's too clever to sabotage actively GCC4TI: that would make HIM look bad, with no one (of good faith) on his side to excuse such an unacceptable behaviour.

As some of us speak quite frequently about the fork in public (especialy these recent days), not opening access to the tools we have (svn/trac, mostly) kind of looks like "vaporware"... and it's like if you speak but don't do anything...
(actually, that's sort of what you say kevin does : spending time trolling, and not integrating your patches)

So, as the fork is not a secret, opening might be a proof of... open-mindness (or something like that)

Lionel Debroux (./2) :
If Kevin sabotages our infrastructure, he should indeed be banned.

I still hope he's not as childish as some of us think... (even if I don't trust myself that much on this subject ^^ ) ; and as you pointed out, he most certainly kowns it'd just be a pure waste of time (both his and yours/ours) as reverting to a previous revision is not hard at all... even if we have better to do of our time.


(I should have answered on the mailling-list, in french I had forgotten how hard - and slow ^^ - it is to write in english, even if I read it easyly )

Sasume (./1) :
I need to understand the deep arguments for and against the opening of the SVN...
I'm for opening the fork. If Kevin Kofler does anything bad he could be banned, no ?

The SVN will never be open for everyone for writing. But it is already open for everyone to read it and checkout.
But I don't mind if the trac & svn links are display on public area, but I think that the Wiki should be a little more filled... It's nearly empty actually, especialy about the project...

I think we should lead this project for itself and not for going against KK. Nothing good will come out from defining something by what we don't like.
We should developp gcc4ti for gcc4ti and not based on what KK might do.

Discussion d'avant-hier soir sur #GCC4TI:

<Lionel_Debroux> Ping ?
<godzil> Hello
<godzil> Pong
<godzil>
<Lionel_Debroux> OK. J'ai commencé à regarder de mon côté le renommage TIGCC -> GCC4TI...
<Lionel_Debroux> ... et ça fait quand même pas mal de fichiers.
<Lionel_Debroux> Jusqu'à quel point penses-tu qu'il est sensé de le faire ?
<godzil> je sais pas
<godzil> j'aurait tendance a dire partout, mais bon si c'est dans le code par exemple, ça peut se faire au fur et a mesure
<godzil> (genre une variagle "tigccPath"
<godzil> )
<godzil> mais tout ce qui est visible en tout cas devrait etre modifié
<godzil> mais je pense que ce n'est pas la plus grande prioritée priorité
<Lionel_Debroux> Je suis assez d'accord que ce n'est pas la plus grande priorité
<Lionel_Debroux> (faut quand même qu'on mette des features distinctives, aussi ^^)
<Lionel_Debroux> mais je pense que c'est quand même un truc à faire avant de rendre publique l'URL du Trac
<Lionel_Debroux> (qui donne les autres), non ?
<godzil> oui
<godzil> "qui donne les autres" ? cad ?
<Lionel_Debroux> La page principale du Trac donne les URL de la ML, du forum, et l'IRC.
<godzil> oui il faut au moins que les trucs visibles sur une install soit renommé c'est certain avant une rendu publique
<godzil> oui ?
<Lionel_Debroux> Il y a quelques trucs qu'on ne pourra pas renommer, par exemple les variables __TIGCC*__ de version.h
<Lionel_Debroux> ... ou la TIGCC Tools Suite, aussi, je vois pas trop comment la renommer
<godzil> Hum
<godzil> on pourrait tres bien avoir des aliases
<godzil> _TIGGG*_ == _GCC4TI*_
<godzil> enfin bref a vrai dire je trouve que les nom __TIGCC*__ mal choisi
<godzil> du moins si ce n'est pas spécifique au compilateur
<godzil> car il me semble que certain sont spécifique a la plateforme
<godzil> on pourrais tres bien avec un #define TIGCC_COMATIBILITY
<godzil> (+P)
<godzil> qui convertit automatiquement les variables de tigcc qui sont nommé explicitement TIGCC et specifique "plateforme"
<godzil> je sais pas si tu vois ce que je veux dire
<Lionel_Debroux> Il y a peu de choses explicitement nommées TIGCC:
<Lionel_Debroux> __TIGCC__ __TIGCC_SP__ __TIGCCLIB__ __TIGCC_VERSION__ __TIGCCLIB_VERSION__ __TIGCC_BETA__ __TIGCC_MINOR__ __TIGCCLIB_SP__ __TIGCCLIB_MINOR__ __TIGCC_VERSION_STRING__ __TIGCCLIB_VERSION_STRING__
<Lionel_Debroux> On pourrait effectivement créer des alias pour ces #defines, c'est le plus simple.
<godzil> disons que les TIGCC version
<godzil> on pas gd chose a faire/avoir avec notre projet
<godzil> meme si on est lié
<godzil> __TIGCC__ il me semble que c'est le define qui indique que le source va etre compilé pour les TI68K non ?
<Lionel_Debroux> __TIGCC__ est le numéro de version majeur de TIGCC. Je l'utilise dans ExtGraph pour savoir si j'ai affaire au compilateur TIGCC, qui le définit par défaut.
<Lionel_Debroux> Typiquement, GTC ne le définit certainement pas.
<Lionel_Debroux> Tu penses qu'il ne faut pas laisser, par les numéros de versions, une indiquation d'un certain niveau d'équivalence de fonctionnalités entre TIGCC et GCC4TI ?
<Lionel_Debroux> -indiquation +indication
<godzil> ok
<godzil> si
<godzil> dans un sens si
<godzil> mais
<godzil> enfin je sais pas
<godzil> a discuter
<godzil> c'est pas que je veux "bannir" tigcc de gcc4ti
<godzil> ça serait déraisonable
<godzil> mais
<godzil> tant qu'a faire, j'aimerais que tout soit bien fait et réfléchi
<godzil> et je trouve que déterminier si on va etre compilé pour une TI68k en utilise __TIGCC__ n'est pas le meilleur moyen...
<godzil> Apres
<godzil> ce que je pensais
<godzil> c'est que l'utilitaire gcc4ti
<godzil> (ou je sais pas si on l'appelerais comme ça)
<godzil> pour remplacer le tigcc actuel
<godzil> pourrait tres bien avoir un lien sybolique vers qui ce nomme lui "tigcc"
<godzil> qui compile en un mode de "compatibilité" TIGCC
<godzil> (ie définir les variable "classiques" de TIGCC etc...
<godzil> et
<godzil> dans GCC4TI "normal"
<godzil> fournir un truc genre "__TIGCC_COMPATIBLE__
<godzil> "
<godzil> par exemple
<godzil> je sais pas
<godzil> un truc dans le genre quoi
<godzil> !op Lionel_Debroux
Mode change "+o Lionel_Debroux" on channel #GCC4TI by Aeris
<Lionel_Debroux> Je pensais aussi à faire un utilitaire 'gcc4ti' et un utilitaire 'tigcc', le premier pouvant avoir des comportements différents de ceux de l'utilitaire 'tigcc'
<godzil> (yapa de raison ^^)
<godzil> dans l'idéalitée des choses
<godzil> je prefererais un bon vieux "gcc" ou "cc" mais c'est pas trop possible vu la toolchain qu'on a
<Lionel_Debroux> Le défaut de séparer 'gcc4ti' et 'tigcc' (ainsi que 'tprbuilder' et un utilitaire plus évolué) est que ça ne rend pas transparent pour l'utilisateur le changement TIGCC -> GCC4TI
<godzil> certe
<Lionel_Debroux> Ouais, on ne peut pas passer à "gcc" ou "cc", clairement.
<godzil> heu
<godzil> pourquoi pas transparent ?
<godzil> au contraire je trouve
<godzil> par contre ça peut ne pas aider a une migration
<godzil> le gars qui ne sais utiliser que tigcc n'utilsera peut-etre jamais gcc4ti
<godzil> (meme en installant gcc4ti)
<godzil> par contre afficher un gros warning
<godzil> peut servir
<godzil> "Attention vous utilisez un outils de compatibilitée pour le portage TIGCC->GCC4TI"
<godzil> ou un truc gdu genre
<Lionel_Debroux> Voilà, c'était plutôt au sens de rendre la migration difficile que je pensais que c'est un défaut d'avoir des outils séparés.
<godzil> "Si vous voulez plus de fonctionalitée, utilisez gcc4ti a la place"
<godzil> d'ou mon idée d'un simple lien symbolique
<godzil> enfin pour l'utilisateur ça change rien
<Lionel_Debroux> D'accord pour l'idée de mettre des notes telles que celles que tu as décrites.
<Lionel_Debroux> Mais faut d'abord les coder, les fonctionnalités supplémentaires :'(
<godzil> oui
<godzil> C'est certain
<godzil> par contre
<godzil> je pense, qu'au moins au début
<godzil> un "tigcc" va etre indispensable
<godzil> meme si le nombre de devellopeur est en forte diminution
<godzil> bon nombre risque de demander "ou est passé tigcc ?"/"j'ai tapé tigcc source.c ça ma dit 'tigcc not found', bref gcc4ti c'est dlamerde!"
<Lionel_Debroux> Yep, c'est clair que l'outil 'gcc4ti' ne doit apparaître que dans un second temps ^^
<godzil> va falloir ecrire un migration guide
<Lionel_Debroux> Pas sûr, si tu regardes la todo/wish list: il n'y a pas tant de choses que ça qui nécessiteraient une migration.
<Lionel_Debroux> A la limite, des TPR améliorés ("GCC4TI Projects") si on implémente un jour ça dans 'gprbuilder' et les IDE.
<godzil> Certe ^^
<Lionel_Debroux> $ grep -Rn "TIGCC" trunk | wc -l
<Lionel_Debroux> 2272
<Lionel_Debroux> Meuh.
<Lionel_Debroux> 3740 occurrences case-insensitive.
<Lionel_Debroux> Certes, il y a des centaines d'occurrences dans les patches aux binutils et à GCC, les changelogs / revision histories, etc.
<godzil> ouch :/
<Lionel_Debroux> J'en suis actuellement à 1453, après tri partiel.
<Lionel_Debroux> (1453 en recherche case-sensitive)
<godzil> ok
<godzil> tu veux "précipiter" l'officialisation du projet ?
<godzil> (du moins le rendre publique)
<Lionel_Debroux> Pas spécialement. Faudrait que je relise des mails d'il y a un certain temps sur la ML, mais il ne me semble pas qu'il y ait de majorité claire pour rendre public le fork...
<Lionel_Debroux> ... avant d'avoir fait quelques modifs visibles pour les utilisateurs et un packaging permettant de "consommer" GCC4TI tout prêt.
<Lionel_Debroux> Mais le processus de compilation & packaging prend du temps
<godzil> c'est bien pour ça que je souhaite l'automatisé
<Lionel_Debroux> Ouais, c'est clair ^^
<godzil> (-é+er mais bon)
<Lionel_Debroux> Mais justement, faudrait pas faire une release publique avant cette automatisation, et une release publique suppose au minimum des centaines de renommages dans les fichiers.
<godzil> j'ai un outils, il me reste a le maitriser
<godzil> et a le faire fonctionner :/
<godzil> ben deja
<Lionel_Debroux> Les renommages dans les fichiers sont typiquement le truc qu'il faudrait faire à plusieurs pour que ce soit moins ch***
<godzil> il faut que j'arrive de toute maniere a le compiler
<godzil> renommage.. ou non
<godzil> d'ailleurs le renommage ne devrait pas modifier la compilation automatique :/
<godzil> enfin sauf pour des points délicats, mais si le makefile (ou equialent) est bien fait
<godzil> il ne devrait pas en avoir besoin
<godzil> c'est pas faux!
Signoff: godzil (Ping timeout)
godzil (godzil@Wnet-28662.w90-2.abo.wanadoo.fr) has joined channel #gcc4ti
Mode change "+o godzil" on channel #GCC4TI by Aeris
<Lionel_Debroux> J'ai pas encore regardé jusqu'aux modifications du processus de build, mais c'est plus la doc qui va je pense faire bizarre si on ne mentionne que sporadiquement "GCC4TI".
<Lionel_Debroux> Je pense que je vais faire au moins deux topics sur le forum: "rédaction du GCC4TI manifesto", ou pourquoi le fork; "quand doit-on faire une release ?", contenant notamment un résumé de cette discussion.
<Lionel_Debroux> Mais peut-être pas ce soir, je sais pas si j'aurai le temps.
<Lionel_Debroux> Au pire, bonne soirée/nuit

Se repose donc la question, sur laquelle on n'a pas pris de décision super claire l'autre fois, de ce qu'on pense utile de faire avant de publier l'adresse du Trac (qui donne toutes les autres)

Mon vote à moi : rendre public le trac dès maintenant.

squalyl vote sur la ML:

-changement de logo: indispensable je pense
-publication: on a intégré les trucs qui nous manquaient avant le fork?
faudrait publier le tout avec une release à mon avis.

PS: quand on fait "reply" sous gmail on répond à l'envoyeur du mail et pas à
la liste, je crois que c'est configurable dans le gestionnaire de listes, ça serait plus pratique

Je réponds sur la ML:

> -changement de logo: indispensable je pense
> -publication: on a intégré les trucs qui nous manquaient avant le fork?
> faudrait publier le tout avec une release à mon avis.
A part:
* stdint.h (dont l'utilité pratique se limite à des portages de rares softs l'utilisant...), ticket #21;
* flashos.a, ticket #11;
* ma version du cleanup des fichiers de doc désapprouvée par Kevin, ticket #3 (fermé).
(toutes les trois des features peu visibles pour l'utilisateur)
on n'a *actuellement* rien intégré de ce qui nous manquait avant le fork. Voir la todo/wish list: http://trac.godzil.net/gcc4ti/report/1

Les patches de PpHd pour le linker (ticket #17) sont en cours. Je n'ai pas encore récupéré la documentation écrite par PpHd dont il parlait dans un précédent mail.

J'ai mis en pause l'optimisation de ld-tigcc par l'utilisation de structures de données plus intelligentes. Ca serait un truc "vendeur" pour le fork.

On ne pourra pas intégrer toutes les optimisations de TIGCCLIB qui ont pu être envoyées à Kevin: on ne connaît tout simplement pas ce qui a pu être envoyé à Kevin, il ne l'a pas rendu public (pour autant que je sache - ou alors c'est un lien obscur, comme contrib.zip et flashosa.zip).

Mouarf. Vu que j'ai oublié l'alim de mon PC portable au bureau (je bosse sur ma machine perso, plus rapide), ça va être plus difficile d'avancer ce week-end

Huh? I have no intentions whatsoever of sabotaging your infrastructure! Why would I? That would be illegal, hurt my reputation more than yours and be ineffective in stopping you. (It's not hard to come up with a new one.) Please quit the nonsense accusations.

Well, isn't it clear that ./2 , especially the last paragraph, expresses strong doubt about you sabotaging the infrastructure ?

But it's a fact we envisioned the *possibility* of you sabotaging the infrastructure, though we knew it was VERY unlikely. As you wrote yourself in ./12, it's the kind of PR storm that nobody wants to trigger, not to mention it's illegal and ineffective.

Why on earth did we envision this possibility ? Simple
Your despise against us, our goals and our work ("votre mailing list pourrie", etc.).
Your threat to sabotage the code, mentioned in ./2.
Your sabotaging of the Microsoft Wikipedia article ( http://en.wikipedia.org/w/index.php?title=Microsoft&diff=prev&oldid=63166346 , edit made by the same IP that is the main editor of the TIGCC page...), showing how constructive you can be when you don't like something or somebody else.
Et caetera.