Mais si le CVS devient un mécanisme de migration de patches en sens unique (parce que vous n'êtes pas disponibles pour publier vos patches sous la même forme), quel autre choix me laissez-vous?

Votre façon de faire, c'est tout piquer et rien rendre.

Non mais sérieux, tu crois à ce que tu écris ??
Ca serait grave que tu croies à ce que tu écris, parce que tu sais pourtant très bien (tu nous pourris suffisamment de topics avec libre/propriétaire...) que c'est juste IMPOSSIBLE qu'on fonctionne comme ça à moyen et long terme. En effet, on part de code GPL/LGPL. Si on partait de code BSD, on pourrait - mais là, même au cas où on voudrait, on ne pourrait pas...

./36 écrit, probablement en plus clair et plus concis, ce que j'avais envie d'écrire.


Pour le moment, même si on approche la vingtaine de personnes au courant de quelques URL, ces URL ne sont pas encore postées sur un forum TI-68k ou un site de news. Mais vu qu'il y a maintenant deux topics en causant - les deux ayant été créés suite à un post de ta part - et que yAronet est bien browsé par les moteurs de recherche, l'existence d'un fork est DEJA officielle.
A titre personnel, comme je l'ai déjà écrit au moins deux fois, dans l'état actuel du fork, je vois moyennement l'intérêt de faire une release (accompagnant, dans mon esprit, l'officialisation du fork), parce que faire une release est du boulot, comme tu l'écris du reste toi-même. Mais d'autres semblent être pour un post plus précoce des URL. Suivant les avis qui seront postés, je me rangerai à l'avis de la majorité. C'est aussi ça, le développement communautaire: discuter à plusieurs, de façon argumentée, sur ce qui nous semble bon à chacun de faire, et décider

Et vu la manière de laquelle tu décris utiliser git (et en présupposant que vous fonctionnez tous comme ça), même si tu ouvres ton dépôt git central au public, on n'aura pas droit aux derniers développements, donc ta promesse est un mensonge.

Non seulement tu ne sais pas comment je bosse et comment je compte bosser... mais de plus, je pense que tu méconnais les possibilités de Git

parce que si jamais la branch introduit un problème subtil que tu ne détectes que longtemps après - c'est régulièrement le cas sur le kernel Linux, par exemple - tu ne pourras pas savoir laquelle des modifs individuelles de la branch a fait merder un cas qui fonctionnait auparavant.

Si, tu peux, en faisant la bissection sur la branche.

OK, je reconnais que j'ai écrit une ânerie. Ce qui est mauvais, quel que soit le SCM, c'est de réduire plusieurs commits à un seul.
Mais en utilisant uniquement CVS, dont le branching a toujours été affreux (comme le reste), je t'en prie, essaie rien qu'une fois, pour voir à quel point c'est amusant de faire une bisection sur une branch
Avec SVN, c'est déjà beaucoup plus facile, même si ça reste (à l'heure actuelle) non automatique.


[EDIT: cross.

+1 ./38, ./40, ./41 .
A titre personnel, je n'ai pas l'intention de continuer encore longtemps cette discussion, vu comment il semble difficile pour Kevin de comprendre ce qu'on essaie de faire. En revanche, il lui est facile de nous critiquer... Je pense que je la fermerai quand Pollux sera venu causer du packing des moves de GTC, dont il me semble me souvenir.

Mais ce que tu dis, en clair, c'est que vous n'avez aucune vraie innovation, juste les patches que j'ai refusés?

Non, c'est toi qui interprètes ses messages comme ça
Mais si ça t'amuse de croire ça, fais donc: ça ne fera qu'un peu plus ou un peu moins de flou dans ta tête sur nos intentions, nos méthodes, notre organisation et nos conceptions. Ce flou n'étant, pour la dernière fois, que très temporaire, parce qu'il disparaîtra quand les URL seront publiques et que tu pourras, enfin, savoir ce qu'on trafique...]