Pour que Kevin puisse s'exprimer librement - Page 1

voila, parce que l'autre topic n'a pas vocation à troll.
Feedons joyeusement ici sans interférer dans le boulot sérieux, merci.

Kevin Kofler (./588 à coté) :
Au fait, à quand une release du fameux installeur?

Tu prévois d'inonder tous les médias? Je me suis laissé dire que tu avais déja exprimé ton opinion ailleurs, je pense que ça va maintenant hein...

sur le forum de codeblocks, chaque fois que quelqu'un demande quand sortira la prochaine release, elle est repoussée de 6 mois. Je sens que ça va s'appliquer ici aussi.

de toute façon plus tu insisteras et plus tout le monde se fera un plaisir de s'opposer à toi rien que pour le plaisir même si c'était releasable. D'une certaine manière c'est un peu à cause de toi, en fait.

squalyl (./1) :
sur le forum de codeblocks, chaque fois que quelqu'un demande quand sortira la prochaine release, elle est repoussée de 6 mois. Je sens que ça va s'appliquer ici aussi.

sauf qu'ils sont en train de réfléchir à une manière de pouvoir releaser réellement tous les 6 mois
http://forums.codeblocks.org/index.php/topic,11896.0.html

Comme Kevinou l'a expliqué dans l'autre topic:

Release early, release often.

Venant de lui, c'est vraiment très crédible

Et sinon, si j'ai posé la question (./588) ici, c'est parce que j'aimerais bien avoir une réponse de l'intéressé direct et pas de deuxième ou troisième main.

ExtendeD (puisque j'imagine que c'est à lui que tu fais référence), et les autres, préfèrent bosser que passer très régulièrement sur les forums - ou du moins, ils préfèrent bosser que répondre à des gens qui connaissent parfaitement la réponse puisqu'elle leur a déjà été donnée plusieurs fois. Et ils ont bien raison.

Je ne vois pas à quoi tu veux en venir avec ton attaque ad hominem: même s'il n'y a pas eu de release formelle depuis un certain temps, TIGCC est développé ouvertement et tout mon travail est public dans le CVS; de même le SVN des apps CalcForge est public, tu peux vérifier exactement ce qui reste à faire comme travail de renommage (pour t'épargner le boulot: toutes les références à "LPG", "TiLP" et "TiEmu" dans les applications, le logo et l'icône de CalcForgeLP, l'exécutable gfm (trop générique) à renommer en calcforgelp-gfm).

La duplicité entre ton comportement sur les forums et sur des canaux de communication que tu contrôles est sidérante...

ton attaque ad hominem

Tu serais autorisé à t'en plaindre si tu n'en étais pas toi-même un spécialiste (je suis bien placé pour le savoir, étant une de tes principales cibles). Tu ne respectes pas les autres, ils ne te respectent pas: c'est normal.

TIGCC est développé ouvertement

Tu aimes radoter tes mensonges, mais (on te l'a déjà expliqué je ne sais pas combien de fois) ça ne les fera jamais passer magiquement de l'état de mensonge (tout le monde ici sait pourquoi) à l'état de vérité

tout mon travail est public dans le CVS

D'une part, ça reste à démontrer - et d'autre part, du travail, il n'y en a plus

Écoute, je ne vais quand-même pas te donner un accès SSH à ma machine personnelle juste pour que tu vérifies que je n'ai pas de modifications non committées! Je te jure qu'il n'y en a pas, je ne suis pas adepte des code dumps de masse "powered by git-svn", moi.

que je sache release often release early ne s'applique pas à la multiplicité des commits svn mais à la publication de RELEASES puisque c'est bien de ça qu'on parle.

D'autre part qui te dit que ce code sera releasé sous GPL ou sous une licence open source? Dans ce cas rien ne nous oblige a rendre le process de développement public.

(juste pour information les canaux d'information, et autres forum ou site, lionel ne les controle pas. Si il me pete de tout fermer, je peux tout fermer. Je ne le ferrais pas pour plein de raison, mais c'est moi qui ai le controle, pas lionel)

Je te jure qu'il n'y en a pas

Pour ce que ta parole vaut, à cause du décalage entre les paroles et les actes...

je ne suis pas adepte des code dumps de masse "powered by git-svn", moi.

Que veux-tu, moi, j'aime les méthodes modernes pour le travail bien fait: commits progressant dans un ordre raisonnablement logique, et de préférence bisectable. C'est la bonne solution, utilisée par plusieurs des plus importants projets ouverts (Linux, X.Org, Wine, et bien d'autres). De plus en plus de monde s'y met, et tant mieux !
Ca n'est pas vraiment ma faute si tu ne consultes pas les canaux de communication où les patchsets transitent

que je sache release often release early ne s'applique pas à la multiplicité des commits svn mais à la publication de RELEASES puisque c'est bien de ça qu'on parle.

D'autre part qui te dit que ce code sera releasé sous GPL ou sous une licence open source?

En effet, rien ne le dit. Ne pas releaser les exploits sous une licence ouverte offre clairement des avantages, et je suis sûr que ceux qui font l'exploit le savent.

squalyl (./7) :
que je sache release often release early ne s'applique pas à la multiplicité des commits svn mais à la publication de RELEASES puisque c'est bien de ça qu'on parle.

C'est une partie, mais il y a aussi le développement public.

D'autre part qui te dit que ce code sera releasé sous GPL ou sous une licence open source? Dans ce cas rien ne nous oblige a rendre le process de développement public.

Bah, vous y perdez à développer tous seuls dans vos coins. En développent ouvertement et sous une licence qui encourage les contributions (donc libre), tout le monde pourrait participer. Le prototype étant là, le transformer en un installeur "production" avec un beau shell et tout serait tout à fait adapté pour un projet communautaire de logiciel libre. Mais pour ça il faudrait publier les sources du prototype et les docs qui vont avec (les détails techniques de l'exploit).

Kevin Kofler (./10) :

squalyl (./7) :
que je sache release often release early ne s'applique pas à la multiplicité des commits svn mais à la publication de RELEASES puisque c'est bien de ça qu'on parle.

C'est une partie, mais il y a aussi le développement public.

D'autre part qui te dit que ce code sera releasé sous GPL ou sous une licence open source? Dans ce cas rien ne nous oblige a rendre le process de développement public.

Bah, vous y perdez à développer tous seuls dans vos coins. En développent ouvertement et sous une licence qui encourage les contributions (donc libre), tout le monde pourrait participer. Le prototype étant là, le transformer en un installeur "production" avec un beau shell et tout serait tout à fait adapté pour un projet communautaire de logiciel libre. Mais pour ça il faudrait publier les sources du prototype et les docs qui vont avec (les détails techniques de l'exploit).

Encore du dogmatisme: tu nous récites la théorie du monde des bisounours, là.
La pratique, c'est qu'on est en train d'ouvrir une plate-forme fermée faite par un fabricant qui n'hésite pas à utiliser des procès sans fondement, et qui serait le premier à nous reprocher (avec raison !) les casses de machines dues à l'utilisation d'exploits non fiables (parce que ça serait sur eux que retomberait le SAV). Ca serait très mauvais en PR pour la communauté que les exploits ne soient pas assez fiables.

Kevin Kofler (./10) :
En développent ouvertement et sous une licence qui encourage les contributions

Mais le mainteneur les encourage-t-il ?

Lionel Debroux (./11) :
La pratique, c'est qu'on est en train d'ouvrir une plate-forme fermée faite par un fabricant qui n'hésite pas à utiliser des procès sans fondement, et qui serait le premier à nous reprocher (avec raison !) les casses de machines dues à l'utilisation d'exploits non fiables (parce que ça serait sur eux que retomberait le SAV).

Ce n'est pas quelque chose qui donne droit à TI de nous faire un procès. (Ils ne sont pas obligés d'accepter ces machines au SAV, donc ce ne sont que les utilisateurs à porter les coûts. S'ils les réparent quand-même, c'est leur choix et leur responsabilité.) De plus, il y a un warranty disclaimer dans toute licence libre sérieuse, et enfin les logiciels offerts gratuitement sont souvent exclus de la garantie par la loi locale (c'est le cas par exemple en Allemagne, où des experts ont conclu que le warranty disclaimer est probablement inappliquable tel quel, mais qu'on ne risque rien si on ne fait pas payer pour le logiciel parce que ça tombe sous le Schenkungsgesetz qui ne prévoit pas de garantie). Donc ça m'étonnerait qu'on puisse vous tenir responsable des casses, vous n'aurez clairement pas fait exprès! (Cela dit, je ne suis pas un avocat et je ne connais pas les détails de la loi française, ce n'est pas un avis légal, à vous de vérifier voire consulter un avocat.)

Je verrais plutôt des procès bidons fondés sur la DADVSI ou autre, mais ce risque restera présent même avec une release bien testée.

cela ne nous donne pas pour autant l'autorisation de pourrir les nspire de tout le monde.

Ben oui, le but n'étant pas de répandre un hack légal quoi qu'il arrive, mais un hack qui ne fout pas en l'air les cals...