Lionel Debroux (./31) :
donc pas un "commit early, release often" sur un SCM centralisé - notons que tu n'appliques d'ailleurs pas à toi-même au moins la deuxième partie de cette devise que tu viens de nous sortir

Je sais que je devrais faire des releases plus souvent. Le problème, c'est que ça prend du temps avec tous les trucs à faire (et en plus le CHM doit être créé sur l'OS propriétaire de destination, je n'ai pas trouvé d'outil qui crée un CHM fonctionnel sous GNU/Linux ou WINE, les outils officiels foirent sous WINE).

Mais moi au moins, je publie toutes mes modifications immédiatement dans le CVS, tu es libre de compiler le CVS HEAD si tu ne veux pas attendre la release.

Le fin du fin serait que tu fermes la maintenance de TIGCC (encore plus que ce qu'elle n'est actuellement, je veux dire) avant de nous laisser le temps de pousser, sous forme d'un changeset qui tient debout (donc pas un "commit early, release often" sur un SCM centralisé [snip, déjà répondu à ça]), des modifs suffisamment visibles pour l'utilisateur par rapport à upstream.

Et qu'apporte cette approche à la communauté, communauté au nom de laquelle vous dites forker TIGCC? Au lieu d'un projet ouvert et communautaire, vous développez en cercle fermé et vous ne publiez que quand vous avez de quoi booster vos égos, c'est l'exact opposé d'un projet communautaire!

Modifs que tu pourrais pourtant, grâce à la GPL et au fait qu'on ne s'amuse pas à changer l'arborescence des fichiers ou faire ce genre de conneries (ben oui, c'est plus de boulot pour nous quand on merge upstream ), réintégrer dans upstream.

Mais visiblement tu as peur que je sorte une release avec ta modif avant toi, c'est pour ça que tu la gardes en cachette. Et tu as bien peur que je fasse la même chose de mon côté, c'est pour ça que tu te bats tellement contre une éventuelle fermeture de mon CVS, alors que ça ne serait que fonctionner de la même manière que vous.

Une fois de plus: je ne veux pas fermer le CVS de TIGCC! C'est moi qui l'ai créé! Et je l'ai fait parce que je crois fortement en le développement ouvert plutôt que sous forme de code dumps. 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?

Exactement comme on peut intégrer les tiennes tant que tu maintiens un repository, avec quelque SCM que ce soit (mais tu n'as manifestement pas envie d'utiliser mieux qu'un des pires SCM, qui ne maintient même pas l'intégrité de ses données...). Ce qu'on te demande, c'est juste de respecter notre façon de faire, dont nous ne sommes pas les seuls défenseurs.

Votre façon de faire, c'est tout piquer et rien rendre. Si vous vouliez vraiment coopérer, vous travaillerez avec l'infrastructure existante et vous vous intègreriez à l'équipe existante au fur et à mesure, exactement comme je l'ai fait. (Je ne suis pas devenu mainteneur en chef de TIGCC du jour au lendemain! J'ai commencé petit, et Sebastian m'a confié de plus en plus de responsabilités au fur et à mesure. C'est comme ça que fonctionne une intégration à une équipe.)

Façon de faire qui changera probablement rapidement, de toute façon: la question n'est pas si on ouvrira l'infrastructure du fork, mais quand... La discussion de 'quand' a été lancée, parce qu'on décide ce genre de choses en groupe.

En attendant, je ne vois toujours rien, j'attends.
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.

En cas d'arrêt des commits sur le CVS public de TIGCC, ce serait encore nous qui aurions le mauvais rôle, tu sais si bien y faire. Même si de notre côté, on pourrait expliquer, ce que je fais plus bas, pourquoi on travaille différemment. Sans cette super bouse de CVS, et comme le kernel Linux et Wine, qui sont, avec tout le respect que je te dois, des projets autrement plus complexes que TIGCC.

Je sais que tu détestes CVS, mais ça ne t'empêche pas de développer en public! Si tu adores git tant que ça, ben il faut faire un push après chaque commit, tout simplement.

On sait très bien que tu es parfaitement capable d'arrêter de committer sur le CVS public de TIGCC. Voir l'antécédent d'avoir décidé avec Sebastian, par-derrière, de splitter le forum de TIGCC/TICT si je réagissais comme tu l'attendais, en me faisant remettre les pouvoirs d'admin par Thomas.

Je ne sais pas pourquoi tu nous sors cette histoire, et de toute façon je pense que ça aurait été mieux pour tout le monde, là on se retrouve avec un forum "TICT" qui discute à au moins 90% de TIGCC et où le seul membre actif de la TICT (toi) n'a aucun pouvoir, je pense qu'avoir des forums clairement séparés aurait été plus pratique que le forum commun qui est un accident de l'histoire.

* merge de toute la branch sur le trunk en une seule révision. Ca, c'est nul,

C'est bien pour ça qu'il faut développer directement sur le trunk le maximum possible. Mon développement se situe sur le CVS HEAD, c'est bien pour ça que KTIGCC a KTIGCC 2 dans HEAD et KTIGCC 1 dans ktigcc-1-branch même si KTIGCC 1 est ce qui est actuellement publié.

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.