Jar Jar Binks a écrit 1200 commentaires

J'approuve, avoir de vraies apostrophes, ce ne serait pas un mal. Ce devrait même être le caractère par défaut de la touche « ' ».

Ce ne sont pas eux qui les modifient, ils se contentent d'approuver le passage vers la distribution gelée de paquets spécifiques.

Puis il explique que le release manager est le seul à pouvoir modifier les paquets.

Non, en période de freeze les release managers sont les seuls à pouvoir approuver le passage de paquets vers testing. Sans ça, ce serait ingérable.

Parce que tu crois vraiment qu'on trouve des remplaçants compétents pour maintenir les paquets ou administrer les machines comme ça ? Sur la dernière année, plusieurs personnes ont abandonné progressivement l'équipe GNOME, et faute de remplaçants ce sont principalement deux développeurs qui s'occupent d'une centaine de paquets. Je doute que les autres équipes aient moins de difficultés à recruter.

Franchement, arrête le délire. Des gens comme Manoj ou Joey qui partent, ils ne sont pas remplaçables. Pas comme ça. Et pas sans de gros retards.

En te lisant je me disais, c'est marrant, c'est aussi stupide que ce qu'un guignol a écrit sur le blog de MadCoder.

Et puis j'ai vu ton pseudo.

Il serait bien que Debian trouve un vrai leader qui serait capable de faire le ménage et vraiment diriger la distribution.

Mais tu devrais être super content, parce que le DPL actuel fait un super boulot de ménage. Il a réussi à énerver (et violemment), le seul FTP-master actif, le responsable de la presse, et des mainteneurs de SELinux, KDE, GNOME, la glibc, SANE, Mozilla, et j'en oublie. Une fois que tous ces méchants râleurs seront partis, c'est sûr, ça va aller mieux.

Franchement je pense que ce type est le mec qu'il faut pour améliorer les choses chez Debian.

Forcément, grâce à ses idées (disons-le) populistes, il s'est fait un nom hors du projet.

Tout le monde avait gueulé au moment du retard de Sarge et ce DPL a été élu largement sur sa volonté d'améliorer les choses dans ce domaine.

Bien sûr. Sauf que les retards de sarge étaient en grande partie dûs à des problèmes avec les ftp-masters. Dont... Anthony Towns. Sans oublier que la release n'a pas avancé pendant un an au départ, sous la direction... d'Anthony Towns, jusqu'à ce qu'il démissionne.

Franchement Anthony Towns il a la classe !

Non mais franchement tu l'as vu ?

Si j'aime Debian, c'est entre autres parce que tous les développeurs y sont (en théorie) considérés de la même façon. En pratique c'est de moins en moins le cas, et on fait avec, mais quand on commence à toucher à l'argent, c'est beaucoup plus sensible. Il y a déjà plein de distributions qui fonctionnent comme ça, et je n'ai pas envie d'y contribuer.

(Je précise, pour ceux qui lisent tout au premier degré, que je ne ressens pas forcément de la jalousie, mais c'est un exemple de comment introduire de l'argent dans un projet de volontaires peut complètement pourrir les relations.)

Quelles sont les priorités il me semble que c'est la communauté Debian qui le détermine non ? Le Debian Project Leader est élu pour cela. Donc la sortie d'Etch en décembre, qui fait partie de la plateforme de ce DPL, est bien un objectif légitime en ce sens qu'il a été approuvé par le vote.

Le vote n'a jamais approuvé le financement de développeurs par d'autres développeurs.

Une fois cela admis quoi de plus naturel que de soutenir les release manager afin qu'ils puissent bosser à plein temps sur cette sortie ?

Quoi de moins naturel, dans un projet géré par le volontariat, tu veux dire.

Putain rejeter le diktat de l'argent en privilégiant l'excellence technique je veux bien mais cela ne doit pas conduire au mépris de l'argent lui même.

Il y a de nombreux développeurs qui sont payés, et ça ne pose de problèmes à personne. Là on a affaire à la fois à un problème de conflit d'intérêts, et à un problème de catégorisation des développeurs. Il y a les développeurs importants (les RM) et les autres.

Tu m'excusera si je me trompe mais je ressent ton post comme soit de la jalousie envers les release managers soit de la puérilité communisto-anarchiste qui vomit l'argent et qui ne veut pas que cet hideux papier monnaie salisse sa belle distro.

Tu peux voir ça comme de la jalousie, c'est exactement ça. Pourquoi je continuerais à contribuer, alors que j'en fais autant qu'eux, si moi je ne suis pas payé par le projet ? Le boulot que je fais moi est donc moins valable ?

Expérience mentale : Imagine que je sois un riche rentier philantrope. Je décide, car j'aime Debian, de filer de l'argent à des développeurs Debian afin d'améliorer la distro. Est-ce bien ou mal ? Tout le monde trouvera ça bien.

Une expérience très ressemblante a déjà tentée, ça s'appelle Ubuntu. Sans m'appesantir sur les détails, je trouve le résultat absolument catastrophique pour le projet.

Mais alors en quoi Dunc Tank est-il différent ?

Il ne l'est pas, c'est tout le problème.

Cela ne me gène pas car ce choix est explicite dès le début, dès l'appel au don. Après les gens donnent ou pas mais c'est en connaissance de cause.

Non, les gens font confiance à la parole du DPL, qui est (comme par hasard) le fondateur de ce projet, pour savoir là où ils doivent mettre leur argent. On ne peut pas demander au quidam externe au projet de savoir juger où il doit investir son argent.

Ça veut dire dicter par les donations (par l'argent donc) quelles sont les priorités et qui doit être payé pour y parvenir.

À part que pour Ubuntu il y a un seul donateur, cela revient strictement au même.

Oh, et Dunc signifie « Development under numismatic control ». C'est assez explicite : l'organisation vise à changer Debian en Ubuntu.

La raison est bien entendu qu'il y a trop de gens qui s'opposent à ce que SPI fasse ce genre de choses. Du coup au lieu d'en tenir compte, hop, une autre organisation indépendante de tous ces râleurs qui ne font qu'embêter les gentils qui veulent la release à temps.

Un projet indépendant certes, mais monté par le Debian project leader, dans le but d'utiliser cette image pour amasser des fonds afin de payer ses potes.

Car bien entendu, les destinataires de ces fonds sont déjà choisis : les release managers. Pourquoi eux ? Mystère, il paraît qu'il suffit de les payer pour que miraculeusement etch soit prête à l'heure malgré les innombrables problèmes.

Décision prise tout de go dès le début donc, mais pour mener l'idée jusqu'au bout en contournant le désaccord violent d'un certain nombre de développeurs, on fait un montage financier pour le moment opaque, qui ne sert qu'à tenir l'affirmation (fausse) selon laquelle il est indépendant du projet.

Ceux qui ont fait ça peuvent être fiers d'eux : le monstrueux troll qui se prépare risque de repousser la release plus loin qu'ils n'auraient pu l'espérer. Sans parler des autres conséquences.

Je croyais que cdrecord était en setuid car le device du graveur était accessible en écriture seulement avec les droits root. Qu'est-ce qui fait que maintenant ça marche?

Non, udev est capable tout seul de créer les devices avec les bonnes permissions :
brw-rw---- 1 root cdrom 22, 0 2006-09-04 15:08 /dev/hdc

Le vrai problème, c'est que les développeurs du kernel ont rendu (sûrement pour de bonnes raisons) certaines ioctl SCSI inaccessibles en tant qu'utilisateur normal. Joerg Schilling s'en est beaucoup plaint alors qu'il suffisait de corriger le logiciel pour ne pas utiliser ces ioctl.

Ça c'est le but de cdrskin.

Cependant, il n'est pas si simple de remplacer un logiciel comme cdrecord. Il y a d'innombrables contournements pour des bugs de matériel, et créer un fork nécessite d'avoir une base d'utilisateurs suffisamment large pour maintenir cette base de contournements.

On est déjà débarrassés de cdrecord pour la gravure de DVD, car dvd+rw-tools joue ce rôle, mais ça manquait pour les CD.

L'exemple de tg3, ça c'est du troll de chez troll. Justement car ce firmware est optionnel et que la carte marche très bien sans.

Microsoft utilise le même argument, mais en France ça s'appelle de la vente liée.

Pourquoi ? Si c'est une carte Intel elles sont au contraire à recommander car très bien supportées sous Linux, y compris pour la 3D.

Toujours rien d'intéressant à raconter ? T'as pas du boulot au lieu de t'amuser à lire les ML d'une distribution uniquement pour pisser dessus ? Tiens, tu n'as qu'à faire comme yeupou, t'y inscrire pour déblatérer des âneries et emmerder les développeurs, dont la part du trafic sur les ML va bientôt descendre en-dessous des 10 % avec les chieurs dans votre genre.

Allez, cet après-midi un petit troll GNOME avec houpla ? Vous allez pisser sur un truc dans votre coin en attendant qu'un gogo vous réponde ? C'est incroyable quand même que des gens s'amusent à utiliser des trucs aussi pourris. Ça doit vraiment être mauvais, Debian et GNOME, vu que vous n'arrêtez pas de le dire.

Décidément, de sacrés branleurs ces astrologues.

PS: si tu as des idées pour améliorer la détection de matériel sous Debian, vas-y, donne-les. Parce que là en fait vu que ça marche les gens se sont penchés sur d'autres problèmes, comme intégrer tout ça pour faire une release. Mais tu as trouvé des problèmes aussi flagrants dans le système de détection du matériel, tu pourrais les signaler aux développeurs.

En l'occurrence je n'ai pas perdu du temps à débattre de ça sur -devel, mais je me permets de prendre 5 minutes pour te faire remarquer que ces histoires d'anti-spam c'est n'importe quoi. De toute façon les adresses email sont présentes à plein d'endroits dans le mail, pas seulement dans les en-têtes, et il n'exite aucune regexp capable de les repérer correctement, surtout pour des ML qui contiennent du code ; en tant que développeur de trucs en perl, tu devrais savoir qu'il est difficile de distinguer une adresse email d'un bout de code perl.

C'est plus que ça : Debian considère qu'il n'est pas légal de distribuer ce code, car c'est un mélange de code non-libre et de code GPL.

Mais il ne l'active pas.

La licence de Python est compatible GPL depuis python 2.1.

Des gens comme toi, je n'ai pas spécialement envie de m'en faire des amis, tu sais.

Où je dis que Debconf ce n'est pas bien ?
Tu n'arrêtes pas de le dire.

Je parle du principe de configurer (manuellement) un paquet lors de l'installation. Je ne dis pas que Debian OBLIGE de configurer lors de l'installation (et d'ailleur tu as déjà répondu à ça).
Donc ce que tu essayes de nous dire, c'est que tous ceux qui utilisent debconf avec une priorité autre que critical sont des crétins, parce qu'ils ne font pas comme toi, euh, comme Redhat a choisi pour eux ?

apt-get, il fait la configuration lors de l'installation ?
C'est comme tu veux. Tu es capable de comprendre ça ? Le CHOIX ?