Sam Hocevar a écrit 73 commentaires

Je vous signale à tout hasard que testing est en freeze depuis presque un mois, et que vous ne risquez donc pas de voir une mise à jour du paquet avant la sortie de Etch...

Avant de me prendre de haut, apprends peut-être à écrire « rhétorique », ça fera un peu moins « houlala je vais vite voir dans Wikipédo ce que je vais pouvoir répondre ».

Je dis que A a pour conséquence B (bugs Ubuntu => retard Etch) et que B a pour conséquence C (retard Etch => davantage de temps pour trouver des bugs), j'en conclus que A est une bonne chose parce qu'elle permet C, et c'est vrai si A n'a pas d'autre conséquence néfaste, j'aurais pu le préciser, c'est vrai, surtout que c'est sur ce point qu'il y aurait lieu de débattre.

Ta démonstration est juste, et ce que tu montres en partant de A' (faire sauter les serveurs Debian) c'est simplement que A' a aussi des conséquences néfastes, donc ce n'est pas une bonne chose. Merci du scoop. Faire sauter les salles serveur, c'est pas bien !

Et sinon, c'est quoi ton vrai problème avec Dunc-Bank, à part ta jalousie malsaine de ma maîtrise de Gimp pour faire des images rigolotes ?

Oh ben oui, j'ai bien compris : non seulement il faut bosser davantage mais en plus il faut le faire avec des intentions saines, sinon houlala c'est mal.

En revanche je n'ai pas encore très bien compris en quoi et pour qui c'était négatif de retarder Etch.

À mon avis les agités du bocal sont ceux qui croient se faire une idée de ce qui se passe chez Debian en regardant le site de Dunc-Bank. Ce site web, c'est un délire, je ne vois pas comment un individu normalement constitué peut prendre ce site au sérieux rien qu'en en voyant les images.

Et excuse-moi, mais qui crois-tu convaincre en disant qu' « au final c'est pas si évident que ça » ? Qui peut imaginer que tout seul, avec la position hyper stratégique que j'occupe dans Debian (y'a qu'à voir les responsabilités de malade que j'accumule, je suis, euh, humoriste en chef, et puis j'ai des centaines d'hommes sous mes ordres qui font tout ce que je leur demande et des fois je les prive de pizza quand ils sont pas sages ou qu'ils ne disent pas assez de mal de Mandriva) je peux retarder de trois mois le travail de 1000 hommes dont plusieurs payés à temps plein ? C'est du délire, ce serait comme si deux mecs armés de cutters pouvaient tuer 3000 hommes dans une tour. Ahaha.

Mais qui a volontairement freiné des deux pieds ? Je n'en connais pas beaucoup ; trois ou quatre, peut-être, et la plupart ne le disent pas. En revanche Dunc-Bank a travaillé d'arrache-pied pour trouver le maximum de bugs RC qui auraient eu un impact négatif sur la distribution si on ne les avait pas trouvés.

Depuis le début j'ai l'impression que tu considères « sorti à la date prévue » comme un gage de qualité ; c'est vraiment un critère bizarre, non ?

Des estimations correctes ? Mais c'est du foutage de gueule à l'état brut, ce que tu dis.

Chaque semaine la release prenait du retard, chaque semaine le nombre de bugs RC décroissait quatre fois moins vite que ce qui était attendu. Et à chaque point fait par les release managers, la réaction était : « on est en retard, eh bien il suffit de travailler plus, et on releasera à temps ».

Dans « release manager » il y a quand même « manager », et aucun des deux RM n'en avait la carrure. Steve Langasek est un excellent technicien, qui a une connaissance parfaite du projet, et abat un boulot absolument énorme ; il n'y a vraiment rien à redire quant à sa contribution technique. Andreas Barth est clairement un cran en-dessous, mais bon, il n'a quand même pas chômé, soyons gentils. En revanche ils ont été soit nuls soit malhonnêtes en gérant le projet :

ø début novembre, ils annoncent un retard du freeze mais pas de la date de release alors qu'il reste 310 bugs ;

ø début décembre, le jour qui aurait dû être celui de la release, il reste 160 bugs, toujours pas de freeze, et on a droit à un nothing too dramatic [...] in good progress ;

ø fin décembre, ils décident de freezer ; il reste 116 bugs alors que la limite avait été fixée à 80, ce qui signifie que le passage des paquets d'unstable à testing sera bien plus ardu, et que le nombre de bugs baissera plus lentement.

Et durant tout ce temps, aucune précision ou amélioration sur le nouveau calendrier ou les outils de gestion (lors de son premier rapport dunc-bank, Andreas Barth disait qu'il avait du mal à estimer les tendances de l'évolution du nombre de bugs parce qu'il aurait fallu pouvoir suivre séparément le nombre de bugs ouverts et le nombre de bugs fermés ; un mois -- de salaire -- plus tard, un tel graphe n'était toujours pas apparu). Alors elle est où, l'estimation correcte ? Dans mon cul, à mon avis.

Alors Dunc-Bank est anti-productif en trouvant des bugs ? Et les release managers de Debian, lorsqu'ils mettent des bugs critiques en etch-ignore parce que « on n'aura pas le temps de s'en occuper », ils sont productifs ? On croit rêver.

Et le but ultime de dunc-tank ce n'est pas de dire « ah ben vous voyez, ça marche on vous l'avait dit, ha ha ! ». Quelle différence ? À part bien sûr que dunc-tank préconise de sortir Etch à une date précise alors que Dunc-Bank préconise de retarder tant qu'on peut trouver des bugs RC.

Je suis par ailleurs surpris qu'aucun donneur de leçons n'ait encore attaqué Dunc-Bank au sujet des images de Skeletor et d'Hannibal Smith qu'on trouve sur le site, à côté d'une liste de bugs énonçant polices et documentations non-libres dans les paquets Debian. 2007 commence mollement.

Avec plaisir. À quel sujet voudrais-tu des éclaircissements ?

Faire l'analogie entre l'impact d'Ubuntu sur les bugs Debian et celui d'une bombe qui fait sauter les salles serveur de Debian, je n'en attendais pas tant. Bravo et merci !

C'est pourtant évident, mais visiblement tu sembles trop aveuglé par ton envie d'insulter. « Pathétique de bêtise, » ça aide à poser les fondements d'une discussion saine.

Si les bugfix d'Ubuntu ne sont pas très faciles à intégrer dans Debian (ce en quoi, soit dit en passant, Dunc-Bank n'est absolument pas responsable, c'est quand même le comble d'attaquer le projet là-dessus !), alors Etch est retardée. Si Etch est retardée, alors nous avons plus de temps pour trouver des bugs critiques et ainsi améliorer la qualité de la distribution.

Sinon, tu peux m'expliquer quelle serait ta stratégie pour corriger les bugs d'Etch qui n'ont pas encore été trouvés ? Parce qu'il faut bien que quelqu'un les trouve ; si tu parviens à les corriger sans les trouver, tu es bien fort. Mais je suppose que tu préconises plutôt de ne rien faire et de nier l'existence des bugs que Dunc-Bank trouve. C'est tellement plus facile, et c'est vrai que ça aide vachement. En plus, en ne faisant rien, on aide toutes les distributions en même temps, c'est un bel exemple de collaboration dans le libre (mais il faut quand même poster des conneries sur LinuxFr.org de temps en temps pour que les gens soient au courant qu'on ne fait rien, sinon ça ne se voit pas assez).

De toute façon un vote public aurait été une hérésie. Tout le monde aurait voté pour le 3e.

Est-ce que Debian fournit le BIOS de ton PC ou des firmwares de PPC et Sparc, ou est-ce que tu parles seulement pour ne rien dire ?

Si vouloir que Etch soit retardé c'est politique, alors vouloir que Etch sorte le 4 décembre c'est politique aussi. Tout le monde fait donc de la politique, mais certains le font en donnant de l'argent à leurs potes sans que le projet ne puisse choisir qui en reçoit, d'autres le font en cherchant des bugs. Je n'ai pas trop à rougir.

Non, pour résumer je donne l'explication du contre-exemple, et je dis que je ne vois pas pourquoi il s'appliquerait à « abasourdir ». Pour « parasol » ça s'explique par la construction « para » + « sol » (une autre construction possible aurait été « parassol » mais apparemment aucun mot en -sol ne double l's : entresol, tournesol, aérosol... on peut presque parler de règle à ce niveau-là). Pour « abasourdir » on peut difficilement admettre « aba » + « sourdir »... apparemment ça vient du vieil argot « bazir » mais je n'ai pas de truc bien sous la main pour vérifier ll’étymologie.

N'exagérons rien : avec les 1000 mots de vocabulaire (et je suis vraiment gentil) qu'on a de nos jours, qui utilise vraiment « abasourdir » ? De nos jours on va dire « étonné », « bluffer », « surprendre », « être sur le cul »...

Ben oui, je n'ai jamais dit le contraire. Pas besoin d'être phonéticien pour savoir prononcer parasol, si ? Je ne comprends pas exactement à quoi sert ta question ; c'est pour contester la prononciation correcte de « abasourdir » sous prétexte que le « s » de « parasol » se prononce d'une façon particulière ?

[s] intervocalique. Et ?

Non mais, euh, il y a quoi d'erroné dans les dicos ? C'est un peu hallucinant comme suggestion. Qu'y a-t-il dans « abasourdir » qui soit si difficile à prononcer ? Même au CP on est capable de lire ce mot convenablement.

La méthode globale aura décidément fait bien des dégâts.

Eh bien ça te fait tout autant de connaissances à qui tu peux apprendre à parler correctement. Illustre-toi dans les dîners mondains en leur signifiant ces erreurs de prononciation comme autant de furoncles à la face de leur diction. C'est exactement comme « carrousel » que tout le monde prononce comme si c'était Cadet Roussel. Super Pédant Man n'a aucune clémence pour ces barbares.

Super Pédant Man présente ses excuses pour la faute d'accord due à une modification vite faite mal faite.

Chaque nom de gare est au moins enregistré deux fois (comme dans la ligne 3 du métro, pour ceux qui connaissent) et à part les chiffres il n'y a pas vraiment de mots enregistrés isolément, mais plutôt des morceaux de phrases.

Faire la même chose à partir de mots seulement, que ce soit pour la SNCF ou pour de la synthèse vocale, serait insupportable à écouter.

Super Pédant Man se permet de faire remarquer qu'on dit « une anagramme » et « un edelweiss », qu'il manque un « h » à « thaïlandais », et surtout qu'un « s » entre deux voyelles se prononce habituellement comme « z » et qu'il ne voit pas pourquoi « abasourdir » dérogerait à la règle. Par ailleurs il faudrait peut-être réenregistrer certains sons comme « confier une tâche » et « tache » parce qu'ils ne font absolument pas la distinction entre « a » ouvert et « a » fermé (d'ailleurs pour cette exemple précis on a même l'impression qu'ils sont inversés).

J'ai écrit Nexuiz, c'était bien entendu Warsow que je voulais dire.

Ce qui confirme bien la tendance que les projets libres trop ambitieux faits « dans le garage » à mourir prématurément : les rares trucs qui sortent un peu du lot sont issus de projets libérés. Pour sortir un gros truc du genre OpenOffice ou Mozilla, je ne vois guère que la libération subite d'un vieux gros truc propriétaire, avec les problèmes concomitants (learning step énorme pour s'approprier le code, difficulté de mettre en place une grosse équipe...) et donc le retard inéluctable de la sortie : si OpenOffice a 10 ans de retard sur MS Office, Nexuiz en a 5 sur Quake 4.

À noter la proposition pertinente qui a été faite dans la liste debian-project de redistribuer aussi l'argent du SoC (il me semble que Debian n'a que 5000$ mais c'est déjà pas mal) à des projets favorisant d'autres minorités, comme debian-niggers ou debian-gay / debian-lgbt.

Certains y verront une discrimination positive malsaine, mais si ça marche pour les femmes...