Dave Airlie (développeur Xorg) nous rapporte une anecdote très *amusante* sur son blog [1].
Tout commence par un rapport de bogue concernant la dernière Ubuntu LTS, les ingénieurs de Canonical bien embêté par celui-ci finissent par le cross-poster sur le bugzilla de Fedora [3] plutôt que de collaborer à le corriger en upstream.
Ce n'est d'ailleurs pas la première fois que Kees Cook (ingénieur sécurité chez Canonical) cross-post des rapports de bogues sur le bugzilla de Fedora dans l'espoir d'un correctif.
Theodore T'so (kernel hacker bien connu) en profite pour étriller Canonical pour sa gestion mesquine du personnel [2] et rappeler que son employeur Google recrute.
Ça donne envie d'acheter du support auprès d'une société qui sous-traite ses rapports de bogues auprès d'une distribution communautaire tierce ! La synchronisation à sens unique tant vanté par M. Shutteworth dans toute sa splendeur !
[1] http://airlied.livejournal.com/72817.html
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/543617/(...)
[3] https://bugzilla.redhat.com/show_bug.cgi?id=588930
Journal Canonical FAIL
5
mai
2010
# Exagéré
Posté par patrick_g (site web personnel) . Évalué à 10.
C'est vrai que le mail de Ted est rigolo, c'est vrai qu'il taille bien Canonical et Ubuntu pour ne pas avoir mis les ressources nécessaires en terme de développeurs....mais l'histoire sur Fedora ça me semble être du bullshit (d'après ce que j'ai vu rapidement).
Une fois que Kees Cook a eu la confirmation que ce n'était pas un bug spécifique à Ubuntu il a décidé de prévenir tout le monde.
Il a donc ouvert un bug en upstream sur le bugzilla du noyau : https://bugzilla.redhat.com/show_bug.cgi?id=588930
Il a aussi ouvert un bug sur le bugzilla de Fedora (celui que tu signales).
Il explique pourquoi : "I've opened an upstream and Fedora bug now, since I've been able trivially reproduce it both on current Fedora and the latest stable upstream kernel".
Donc OK Canonical n'a pas recruté des pointures et en cas de gros bug compliqué ils sont un peu dans la merde...mais dire qu'ils sous-traitent vers Fedora c'est pas vrai.
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 8.
[^] # Re: Exagéré
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Exagéré
Posté par GeneralZod . Évalué à 9.
On peut le voir ainsi, ouvrir un bug en upstream aurait suffi, puis pourquoi ne pas l'avoir fait pour Debian (plus logique), SuSE ou Mandriva ?
> mais dire qu'ils sous-traitent vers Fedora c'est pas vrai.
Je force le trait (histoire de pimenter la discussion), mais ce genre de scénario commence à être un peu trop fréquent pour ne pas être suspect. Surtout que derrière, il y a rarement des remontées vers Fedora.
Qu'on le veuille ou non, Canonical fait partie du paysage et le problème des ressources humaines et des relations avec upstream ne voit toujours pas un début de solution depuis environ 6 ans. Ça nuit à Canonical, et ça n'est pas dans l'intérêt du logiciel libre (un Canonical à la traine techniquement, ça veut dire moins de bras pour corriger les bogues et écrire du code).
Récemment, c'est Upstart (qui est plus ou moins l'init standard des distros modernes) qui traine parce que son mainteneur n'arrive plus à dégager du temps pour bosser dessus ===> Lennart Poettering & cie qui démarre systemd.
C'est d'autant plus regrettable que Canonical a mené une réflexion intéressante sur les outils et la collaboration (j'ai lu un billet très intéressant sur le processus de traduction à ce sujet sur planet ubuntu cette semaine) à travers bazaar, Launchpad mais ne semble jamais aller jusqu'au bout de la démarche.
Par exemple, la faculté qu'à Launchpad de suivre un ticket sur un tracker distant (excellent!) ne semble pas avoir sa contrepartie naturelle: pouvoir signaler sur celui-ci les changements intéressants.
La synchronisation que souhaite tant Shuttleworth est finalement à portée de main mais ça demande plus de mains (et des mains expérimentées) et d'achever le travail sur les outils. Une fois ce pallier franchi, Canonical aura toutes les cartes en main pour devenir un géant.
[^] # Re: Exagéré
Posté par Misc (site web personnel) . Évalué à 1.
Ça aurait permis de faire des outils comme SD plus facilement ( http://syncwith.us/sd/using ).Actuellement, la moitié du support, c'est de l'analyse du code html, c'est un peu moche et fragile.
Mais bon, le but etait pas de faciliter la collaboration, mais de concurencer RH et progeny, cf http://www.erisian.com.au/wordpress/2005/09/04/launchpad
[^] # Re: Exagéré
Posté par ZeroHeure . Évalué à 4.
Ohlà! ohlà! c'est un peu vite dit tout ça. La phrase de Mark Shuttleworth rapportée (en 2005) dans ce blog est
Right now we compete with Progeny and Red Hat and other companies, so we need to have a unique offering to do so effectively, and that’s Launchpad.
Ce qui veut simplement dire que Canonical était en conccurrence avec les autres distributeurs de Linux et qu'il leur fallait se démarquer.
Rien de plus normal. Toutes les entreprises font ça.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 5.
Parce que, comme il le dit, il a reproduit le bug sur Ubuntu et Fedora. Peut-être qu'il n'a que ces deux distros d'installés sur sa machine ?
[^] # Re: Exagéré
Posté par GeneralZod . Évalué à 9.
Pour moi, il était plus logique qu'il commence par rapporter le problème chez Debian, d'une part parce qu'Ubuntu se synchronise régulièrement dessus, d'autre part parce que c'est un DD.
[^] # Re: Exagéré
Posté par dest . Évalué à 9.
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 9.
[^] # Re: Exagéré
Posté par Misc (site web personnel) . Évalué à -1.
Developpement durable ?
Dunkins Donuts ?
Designated driver ?
un tag html, une commande unix
( en effet, google n'est pas trés utile sur le coup :) )
[^] # Re: Exagéré
Posté par NickNolte . Évalué à 4.
Ce n'est pas parce que tu assures niveau dépêche que tu peux te permettre d'écrire en franglais!
C'est la deuxième fois en 2 jours avec le même mot en plus!
En outre, ce n'est que faire honte à notre douce langue qui brille notamment de par ses riches et nombreux vocables grossiers/vulgaires! :)
Qu'on ne t'y reprenne plus!
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 0.
Pipeau ?
[^] # Re: Exagéré
Posté par Maxime Buffa . Évalué à 9.
J'ai une faiblesse pour le français. C'est une langue merveilleuse. J'aime notamment... les jurons français.
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: Exagéré
Posté par NickNolte . Évalué à 3.
[^] # Re: Exagéré
Posté par Quikeg . Évalué à 1.
[^] # Re: Exagéré
Posté par patrick_g (site web personnel) . Évalué à 5.
Faut que ce soit subtil...un acrostiche peut-être ? En tout cas vous n'y couperez pas bande de petits saligauds ;-)
[^] # Re: Exagéré
Posté par imr . Évalué à 2.
[^] # Re: Exagéré
Posté par Obi MO (site web personnel) . Évalué à 0.
[^] # Re: Exagéré
Posté par Maxime Buffa . Évalué à 2.
http://www.wordreference.com/enfr/bullshit
[^] # Bullshit
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
de la bouse tout simplement.
Que celui qui a dit - oui, toi, au fond - que Bull ne faisait que de la merde se fustige avec des orties !
[^] # Re: Bullshit
Posté par fleny68 . Évalué à 2.
[^] # Re: Exagéré
Posté par NickNolte . Évalué à -1.
si tu veux du vulgaire ben:
bullshit="merde"
bollocks="couilles"
voilà quoi...
[^] # Re: Exagéré
Posté par Antoine . Évalué à 5.
[^] # Re: Exagéré
Posté par NickNolte . Évalué à -2.
[^] # Re: Exagéré
Posté par Dr BG . Évalué à 2.
[^] # Re: Exagéré
Posté par 2PetitsVerres . Évalué à 2.
--> []
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Exagéré
Posté par windu.2b . Évalué à 5.
[^] # Re: Exagéré
Posté par cichlid . Évalué à 2.
http://fr.wikipedia.org/wiki/Boniment
envoyé depuis mon clavier bépo
[^] # Re: Exagéré
Posté par thedidouille . Évalué à 10.
# mouhais
Posté par Albert_ . Évalué à 10.
Il est vrai par contre que Canonical ferait bien d'employer quelques developpeurs de haut niveau dans le kernel et xorg (au minimum).
# XLusive
Posté par sirrus . Évalué à -5.
Personnellement je n'utilise pas ubuntu, mais plutôt mandriva et debian, et j'attends impatiemment que notre grand reporter nous apporte une clarté limpide comme l'eau d'un lac de montagne sur les mauvais comportements présents dans ces distributions.
Je pense que ça me poussera à terme à adopter fedora, afin de purifier mon karma de mauvais libriste pas beau.
[^] # Re: XLusive
Posté par Maxime Buffa . Évalué à 8.
[^] # Re: XLusive
Posté par dinomasque . Évalué à 10.
BeOS le faisait il y a 20 ans !
[^] # Re: XLusive
Posté par GeneralZod . Évalué à 2.
Je ne relèverais pas les autres imbécilités.
[^] # Re: XLusive
Posté par sirrus . Évalué à -2.
Je ne remets pas en cause ton esprit de contribution à linux à travers fedora...
Mais tu te rends compte que poster ce genre de bêtises ça ne fait rire que toi ? je veux dire : ça n'est même pas drôle tes tentatives désespérées de troll !
Change de registre : éoliennes, crise européenne, burqa... plein de sujets.
Là c'est toujours du réchauffé : ubuntu gnagna, fedora saileplusmieux. Ça va un peu mais merde à la fin
Signé : ton public déçu
[^] # Re: XLusive
Posté par Thomas C. . Évalué à 6.
[^] # Re: XLusive
Posté par Maclag . Évalué à 3.
- Oui, je rigole aux blagues sur les Belges
- Non, je ne pense pas que les Belges soient plus cons que les autres, et sûrement pas plus cons que les Français
- Oui, je rigole sur les blagues sur Ubuntu
- Non, je ne pense pas qu'Ubuntu soit de la merde faites par des ignares.
Et maintenant, on se détend!
[^] # Re: XLusive
Posté par BAud (site web personnel) . Évalué à 3.
pour être en forme demain ? ;-)
# Web 0.1
Posté par zebra3 . Évalué à 10.
On est sur le web pas dans un bouquin, alors autant se servir de ce qu'il sait faire !
J'avoue que mon coup de gueule est bêtement impulsif, mais ça fait plusieurs journaux que je vois comme ça et je trouve parfaitement énervant de devoir couper sa lecture pour chercher des liens en dessous, surtout qu'en plus ici, l'ordre est inversé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Web 0.1
Posté par zebra3 . Évalué à 4.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Web 0.1
Posté par Grunt . Évalué à 10.
On dit "À moitié inversés", dans ce cas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Web 0.1
Posté par stopspam . Évalué à 9.
On est sur le web pas dans un bouquin, alors autant se servir de ce qu'il sait faire !
entièrement raison !!
D'autant plus que j'ai pris l'habitude au long de ma lecture d'un texte de charger les liens (du texte) en arrière plan dans un onglet. C'est gonflant de scroller et "sortir" du texte pour chaque lien...
[^] # Re: Web 0.1
Posté par Graveen . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Web 0.1
Posté par zebra3 . Évalué à 3.
Pas faux, mais je suppose que le gars capable de suivre les bugtrackers d'Ubuntu et de Fedora est aussi capable de faire un lien HTML.
Et surtout, avec [1][2][3] tu peux mettre plusieurs liens pour un mot...
Avec HTML aussi.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Web 0.1
Posté par GeneralZod . Évalué à 1.
taiste
* syntaxe recommandée dans l'aide mais moche en plein milieu d'un texte.
[https://linuxfr.org/~GeneralZod/29685.html]
C'est pas satisfaisant, mais faute de mieux (si vous avez des suggestions, je suis preneur).
Quant au désordre, comme j'ai l'habitude de déconstruire/reconstruire la structure de mes textes, ça m'arrive souvent.
[^] # Re: Web 0.1
Posté par zebra3 . Évalué à 6.
Désolé pour le coup de sang, mais je trouve que c'est absolument inadapté à la lecture sur le web.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Web 0.1
Posté par GeneralZod . Évalué à 3.
[^] # Re: Web 0.1
Posté par lezardbreton . Évalué à 7.
[^] # Re: Web 0.1
Posté par BAud (site web personnel) . Évalué à 7.
Effectivement, je recopie/colle la phrase laconique que tu avais mise indiquant quelles balises (sous-entendu HTML) sont acceptées (à chacun d'en connaître la syntaxe o_O) :
Les balises suivantes sont autorisées pour le corps du journal : a,p,b,i,s,u,em,tt,strong,ol,ul,li,pre,code,q,cite,acronym.
le <a href="url">texte avec lien</a> est donc bien possible dans un journal ;-)
[^] # Re: Web 0.1
Posté par GeneralZod . Évalué à 2.
Je m'en souviendrais pour le prochain journal "xxxxx FAIL" (qui portera sur une autre distribution)
[^] # Re: Web 0.1
Posté par kowalsky . Évalué à 2.
Non non, je ne crois pas :)
[^] # Re: Web 0.1
Posté par El Titi . Évalué à 2.
[^] # Re: Web 0.1
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Web 0.1
Posté par El Titi . Évalué à 2.
# Bof
Posté par Éric (site web personnel) . Évalué à 10.
Tout au plus tu peux reprocher à Ubuntu de ne pas corriger les bugs upstream de tous les projets mais bon, est-ce réellement leur rôle ?
Que les distributions doivent participer aux développements en finançant des développeurs, d'accord, mais leur rôle c'est l'intégration au départ. S'ils ont un dev compétent sur le sujet ils peuvent faire un patch et le proposer, mais sinon leur rôle s'arrête à mon avis à transmettre aux personnes compétentes, ce qu'ils ont fait (maladroitement peut être)
[^] # Re: Bof
Posté par patrick_g (site web personnel) . Évalué à 10.
Ben ils ont quand même l'ambition de faire une distro utilisable par les entreprises non ? Donc si ils n'ont pas de compétences internes ça va être dur de convaincre....
[^] # Re: Bof
Posté par El Titi . Évalué à 3.
En gros le boulot c'est le packaging pas le kernel, ils ne savent faire que ça.
Avec un discours comme le tien, on se demande pourquoi ils n'ont pas un dev Gnome, et un pour chaque appli....
Après, ce qu'il faudrait c'est qu'en effet ils souscrivent des contrats de garantie auprès de chaque brique lorsque le problème est crucial.
Mais ca veut dire mettre la main à la poche et chacun sait qu'ils ne sont pas riches et qu'en soumettant sournoisement le bug l'air de rien, quelqu'un pourrait le prendre.
Dans ce cas, difficile de donner des garanties au client.
[^] # Re: Bof
Posté par kowalsky . Évalué à 7.
Arf... tu parles d'une distri qui veut que tout les projet se synchronise sur SA sortie et qui ne participe pas dans les projets. Il faudrait pour que ubuntu soit un peu crédible, qu'elle fasse comme RedHat ou Suse, qui ont une tripoté de développeur un peu partout.
Dans ce cas, difficile de donner des garanties au client.
Pourtant c'est ce que ubuntu fait (sans succès commercial).
[^] # Re: Bof
Posté par bubar🦥 (Mastodon) . Évalué à 3.
non ?
[^] # Re: Bof
Posté par kowalsky . Évalué à 7.
Tu ne peut pas te revendiquer comme la distrib LEADER dans le monde de Linux et se comporter comme un vampire. Cette pratique serait acceptable si les gens de Fedora ou autre savaient que chez ubuntu il y aurait des experts en "ce que tu veux" chez ubuntu et ce serait un échange de bon procédé. Mais la, que dalle, il n'y a pas de retour de la part d'ubuntu.
Cette pratique serait acceptable par une distrib communautaire (comme gentoo, slack, debian même). Et encore, non, c'est naze. Il ouvre un bug sur le bugzilla du projet (le kernel ici) et voila tout. Il peut aussi poser des questions sur la bonne mailing list. Mais pas ouvrir un bug chez fedora !
Sinon on va ou (non, pas la) ?
Fedora ouvre un bug chez openSuse, qui ouvre un bug chez microsoft qui ouvre chez OpenBSD qui ouvre chez Debian qui ouvre chez ubuntu. C'est du grand n'importe quoi c'est tout.
Ubuntu chie sur debian, chie sur les projets en les reléguant à un second plan en disant "sortez au bon moment pour être bien dans ubuntu", chie sur KDE en sabotant son image en sortant des versions bugger de KDE (et pourtant KDE avait pas besoin de ça pour les version bancale) et chie sur RedHat (concurrent relativement direct quand même).
On ne voit jamais ce genre de relations entre d'autre ditrib. ça n'existe pas. Il n'y a que ubuntu qui est tant aimé dans l'écosystème Linux.
[^] # Re: Bof
Posté par ZeroHeure . Évalué à 3.
Tu vas dire qu'il bosse pour Ubuntu, mais vu son boulot (sécurité) et sa page de wiki, il a forcément plusieurs distributions sous le coude.
Je pense qu'il a tout bêtement testé ailleurs pour voir si c'était reproductible, peut-être même pour voir si c'était un bug ext4 ou Ubuntu, et qu'il a donc rapporté le bug là où il l'a constaté.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Bof
Posté par imr . Évalué à 1.
C'est vrai que ça n'a pas marché pour microsoft.
Il n'y a que ubuntu qui est tant aimé dans l'écosystème Linux.
La preuve que ça ne marche pas.
[^] # Re: Bof
Posté par GeneralZod . Évalué à 6.
Rapporter le bogue upstream: OK (upstream comprenant bien évidemment Debian dans leur cas)
Rapporter le bogue chez les autres distributions: pourquoi pas, si derrière il y a un échange constructif (j'aurais applaudi des nageoires si c'était le cas). Mais de là à refiler le boulot à une autre distribution et rester peinard à attendre la solution, c'est plutôt moyen comme habitude.
Surtout quand le grand patron fait des belles phrases sur la collaboration entre les distros.
> Que les distributions doivent participer aux développements en finançant des développeurs, d'accord, mais leur rôle c'est l'intégration au départ
Le problème c'est que la société vends du support sur la distribution, tu ne peux pas vendre un support que tu n'es pas capable d'assumer. Si demain, le développeur upstream décède ou refuse de corriger le bogue (genre tu tombes sur un disciple d'Ulrich Drepper), tu réponds quoi à ton client ? Même si tu n'as pas vocation à participer à tout les développements, faut avoir la capacité de répondre au problème si besoin est.
[^] # Re: Bof
Posté par Ronan BARZIC . Évalué à 2.
Donc poster le bug chez RedHat, concernant Fedora, c'est franchement pas déconnant, en supposant en plus que le gars de Canonical, si il n'ets pas un expert noyau, il sait peut-être un peu qui fait quoi dans la communauté
[^] # Re: Bof
Posté par GeneralZod . Évalué à 2.
Red Hat != Fedora, ce n'est pas parce qu'un mec travaille chez RH, que forcément il bosse également sur Fedora (plus de 80% des contributeurs sont issus de la communauté).
Et même si c'est le cas, il est quasi certain que tu tomberas sur les mêmes personnes sur le tracker upstream, donc quel est l'intérêt ? ext4, ce n'est pas un projet Fedora, t'as une belle brochette d'experts en dehors de Fedora (Google en emploie quelqu'un).
Par contre, le bug concerne une LTS (donc une version avec du support commercial), Canonical semble pas fichu de le corriger et n'a pas l'envie/le temps de suivre la résolution du problème avec upstream. Donc la théorie, je refile le bébé au mainteneur Fedora et les laisse se démerder avec upstream pour corriger le bogue, c'est pas déconnant du tout non plus.
Un bon mainteneur n'est pas forcément un bon développeur, être capable de remonter les bogues, les informations pertinentes, être à l'écoute des utilisateurs et des mainteneurs, c'est déjà pas mal.
Theodore T'so ne s'est pas trompé, ça demande de libérer du temps à l'équipe technique (donc embaucher du personnel), ça demande d'avoir des experts (soit en les embauchant, soit en les formant) et de savoir les retenir (cadre de travail agréable, paie conséquente).
[^] # Re: Bof
Posté par Albert_ . Évalué à 2.
Pour des question de kernel? J'ai comme un enorme doute sur le coup...
[^] # Re: Bof
Posté par GeneralZod . Évalué à 2.
[^] # Re: Bof
Posté par Albert_ . Évalué à 5.
De plus celui qui a pondu le bug n'est visiblement pas un specialiste des systemes de fichiers https://wiki.ubuntu.com/KeesCook alors qu'il demande de l'aide ailleurs c'est logique tout de meme surtout si il voit que le ailleurs a le meme probleme.
Cela n'enleve pas le fait que Canonical devrait avoir plus de monde sur le kernel et xorg.
[^] # Re: Bof
Posté par kowalsky . Évalué à 10.
Non, c'est celui de fedora apparemment...
Si ils avaient eu plus de monde, ils auraient corrigé le bug et basta. La le "si" est clairement un aveu de faiblesse de la part d'ubuntu. Pas de monde, pas de débugage.
En fait, bientôt, ils vont ouvrir leur bug n°1 (https://launchpad.net/ubuntu/+bug/1) chez RedHat.
Que les distributions doivent participer aux développements en finançant des développeurs, d'accord, mais leur rôle c'est l'intégration au départ.
C'était vrai mais ça ne l'est plus, surtout quand on vend au client un service. Ils comptent ouvrir un bug chez RedHat ou Suse quand un client leur réclamera des comptes pour un bug qu'ils ne savent pas résoudre et qui n'intéresse personne d'autre ?
Je trouve que cette histoire montre bien ce qu'est Ubuntu : Une distrib qui reçoit beaucoup mais qui donne peu.
[^] # Re: Bof
Posté par genesis83 . Évalué à -2.
Qu'il cherche à faire corriger le bogue par "ceux qui savent" est une chose, qu'il détourne les outils d'une autre distribution à profit d'Ubuntu en est une autre.
Le bugzilla de Fedora est là pour rapporter et traiter les bogues rencontrés par les utilisateurs de Fedora.
[^] # Re: Bof
Posté par patrick_g (site web personnel) . Évalué à 6.
Ben oui mais là justement il avait reproduit le bug avec Ubuntu et avec Fedora. Cela ne me parait pas déconnant de prévenir les gens de Fedora puisqu'il avait la preuve que leur distro était impactée.
[^] # Re: Bof
Posté par genesis83 . Évalué à -4.
Il y a déja plus de bogues que de bras alors chercher à corriger ceux qui touchent la distribution silencieusement... d'autant plus qu'il y a des chances qu'ils soient corrigés upstream avant qu'un utilisateur ne soit affecté.
# Et la timeline ?
Posté par Misc (site web personnel) . Évalué à 10.
ouverture du bug : 21 mars, sur launchpad
prise en compte par surbhi palande : 29 mars
correctif avec un hack : 13 avril
ouverture du bug upstream : 4 mai
envoi d'un premier fix par un dev kernel : 12h plus tard
donc en gros, en une demi journée avec le bug au bon endroit, le bug est en passe d'être corrigé. On va dire qu'on rajoute 1 journée le temps de compiler un kernel vanilla pour vérifier si le bug vient d'un patch. A comparer avec les 3 semaines sur launchpad pour avoir un contournement.
Que les gens de Canonical n'arrivent pas à résoudre, ça me choque pas. Je sais à quel point les bugs peuvent être complexe, je sais qu'en période de release, on a pas le temps.
Mais bon, le fait de pas l'avoir rempli upstream plus tot me laisse perplexe. Je les blames pas, je suis sur que j'ai deja fait et que je ferait (hélas) surement pareil à un moment ou à un autre, par manque de temps, manque de soin, ou autres, personne n'est parfait, moi le premier.
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 4.
Moi j'ai arrete de emplir les bugs sur launchpad pour deux raisons:
- La premiere c'est que avant que un dev ubuntu/canonical n'y reponde tu peux courir ou commencer a leur dire qu'ils commencent a casser les c.... cela les fait un chouilla plus reagir mais cela a generalement exactement l'effet inverse et ton bug ne sera jamais corrige voir pire il sera reintroduit alors qu'il a ete corrige upstream...
- il n'y a JAMAIS de transfert a upstream malgre les grands discours sur launchpad et l'automatisation de la soumission des bugs upstream.
Ah si j'aime beaucoup la facon dont il juge de la gravite d'un bug c'est comment dire... bizarre (un freeze desktop est nettement moins important qu'un menu pas de la bonne couleur).
J'ai trouve plus efficace et beaucoup moins enervant de discuter avec les projets directement (et de ne plus utiliser ubuntu vu qu'ils s'amusent a redefaire ce que upstream a corriger en particulier sur KDE).
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . Évalué à 4.
De plus, je pense qu'indépendament d'ubuntu, il est mieux d'aller directement voir upstream. Moins il y a d'intermediaire, mieux ça marche, au moins pour les grands projets. Et ça rappelle aux developpeurs, qu'ils ont des utilisateurs qui apprécient le logiciel, et qu'ils ne sont pas de simples producteurs à la solde des distros, mais bien au coeur du libre.
[^] # Re: Et la timeline ?
Posté par El Titi . Évalué à 3.
Pour un même projet ou même des projets différents, ca signifie que 2 personnes peuvent prendre en charge le même bug sans se parler, ou à l'inverse, l'ignorer tous les 2 en se disant que l'autre les prendra.
Typiquement pour moi la gestion des changements ne se conçoit qu'en centralisé pour ne pas gaspiller de précieuses ressources.
Alors ma question:
Tu pourrais nous en dire plus ?
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . Évalué à 3.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
De même, si on veut forker un projet de maniére plus compléte, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Et au final, la problématique de la distribution est déja connu au niveau du code, il suffit de décreter une instance comme étant canonique, tout comme l'arbre git de linus est l'arbre officiel.
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).
[^] # Re: Et la timeline ?
Posté par El Titi . Évalué à 1.
Tout d'abord, on peut imaginer ça pour travailler de maniére offline. Exemple, je suis dans le train, je suis la ou l'accés au net est pourri, ou je veux me concentrer sans être dérangé ( et donc je coupe le réseau ), j'ai mon bts offline pour bosser. Ça marche aussi si le bts est down, ou en maintenance.
Si je suis en offline et que je prend un bug pour le debugguer sans prévenir, rien ne garantit qu'un autre ne fera pas la même chose
en même temps. Travail ingrat et redondant.
A la limite pour mettre à jour le statut des demandes qui me sont affectées avant la déconnexion ou pour les instruire ok.
Ensuite, pouvoir distribuer le bug tracker, ça permet aussi de faire facilement des forks.
Exemple, je fait une release, je fait un fork du code, pour la branche stable. Pour la liste des bugs reports, c'est pareil, j'ai une branche stable, et une branche dev. avec une gestion différente, et une durée de vie différente.
Sauf qu'en général on déclare un seul un bug report qui donnne lieu à un changement ou plusieurs changements disjoints et c'est ce(s) changement ( changeset) qu'on répercute sur chaque branche. Ces changements référencent un seul et même défaut.
De même, si on veut forker un projet de manière plus complète, on peut. Le mainteneur est con, ne réponds pas, etc, on prends la liste des bugs, et on se barre. La liberté de base appliqué à la gestion de projet, comme pour le code.
Combien de projets sont vraiment forkés ?
Parler, convaincre , faire des compromis c'est pas mal aussi.
Ensuite imagine qu'une personne poste un bug sur ton fork "hostile".
Comme vous ne vous parlez plus, chacun le corrigera de son coté avec des conflits de merge inutiles ou chacun attendra que l'autre ait pris en compte le bug pour récupérer la correction en pull. Je demande à voir.
Ça permet aussi d'avoir une TODO list personnel. Par exemple, je veut bosser sur tel driver du kernel. Je prends les bugs, je corrige, et je garde liste de ce que j'ai corrigé cote à cote avec le git.
Y'a Mylin pour ca. Allez admettons !
Avoir la liste des bugs chez soi, ça permet de faire des traitements qu'on peut pas forcement faire à cause de la latence réseau, ou parce qu'on a pas les accés complets. De la recherche full texte, des requetes sql, des stats, etc.
Au prix d'une plus grande complexité.
Avec la gestion de conf on y trouve son compte, mais là le jeu en vaut t'il la chandelle ?
Dans le cas de Ubuntu, un bts distribué, ça permet aussi de pousser tout le bug upstream comme on pousse une branche git. Donc les commentaires sont preservés, et on peut imaginer merger les fils de discussions, ( ie, les discussions sur le bts fedora, sur le bts debian, etc ).
Avec le risque que cette façon de déléguer le taf soit accueillie fraichement comme sur le journal.
Dsl j'ai du mal à accrocher.
Dans les faits, quand ca plante quand tu cliques ici, tu postes ca sur Ubuntu. Le mainteneur Ubuntu (je sais c'est pas un bon exemple) qualifie le bug et instruit un nouveau "bug request" chez tous les projets qui sont concernés si le bug dépend de plusieurs pbs corrélés.Il instruit sa propre demande comme dépendante de la résolution d'autres et patche chez lui ce qui le concerne, si nécessaire.
Pas besoin de réplication de bug request pour tout ça.
Mais je ne demande qu'à être convaincu et j'espère que tu nous posteras une jolie dépêche quand ca sortira.
[^] # Re: Et la timeline ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . Évalué à 2.
http://syncwith.us/sd/using . Et l'auteur va en parler lors des RMLLs
et y en a d'autres, cf http://lwn.net/Articles/281849/
Enfin, tout comme les dvcs actuelles, rien ne t'oblige à t'en servir de maniére decentralisé, donc la dichotomie que tu mets en place est totalement fausse. Si tu veux garder une façon centralisé de l'utiliser, tu peux, c'est juste que maintenant, les gens ne sont plus forcer de le faire. Si tu lit bien le site de SD, tu va voir qu'il est capable d'importer depuis trac, depuis redmine, etc.
L'exemple d'un bug qui est corrigé par plusieurs changeset est justement un exemple du probléme. Dans bugzilla, un bug affecte 1 version uniquement. Si je prends l'exemple de Mandriva, je trouve un probléme dans un paquet stable, le correctif doit passer la QA de façon formel, mais pas dans la version de dev. Le bug est donc dans un état sémi résolu ( corrigé dans une version et pas dans une autre ), et c'est un peu moche. Trac, mantis, et d'autres ont aussi ce modéle ( 1 bug == 1 version ).
Launchpad n'a pas ce modéle, mais du coup, comme il y a un fil de discussion par bug, on sait pas qui parle de quoi. Quand quelqu'un dit "le bug est corrigé pour moi", il faut qu'il précise dans quel version etc. Et donc ça entraine des risques d'erreurs.
Avec une instance forké d'un bug tracker par produit, c'est bien plus simple. On peut même imaginer qu'un revendeur d'un produit gére son propre bug tracker, ce genre de choses.
Les projets basés sur Ubuntu pourrait ainsi remonter les bugs plus facilement, tout comme les kernels hackers font passer leur patch d'un arbre à un autre aprés validation.
Tu parles de prendre les bugs pour debugger sans prevenir, je sais pas sur quel projet tu bosses, mais sur tout les projets ou je bosse, les gens corrigent sans prévenir, car les risques de collisions sont faibles. Quand il y a 5 personnes sur un projet, les gens vont rarement tous au même moment, sur le même truc. Et c'est bien plus lourd de prevenir que de corriger les rares problémes quand on le fait pas.
Et le probléme existe de toute façon deja avec un bts classique, donc je ne voit pas en quoi c'est génant ( à ce que je sache, personne ne va dire sérieusement "ah mais non, corriger le code sans le dire sur le bugzilla, ça va poser des problémes, faut empecher que ça arrive en forcant techniquement ça".
Quand à l'histoire des forks hostiles, rien ne dit que les gens doivent communiquer, le truc de base, c'est juste de pouvoir avoir une copie.
Pour l'histoire des bugs report, tu semble juste voir le coté "j'exporte les bugs chez les autres". Mais ça peut aussi être l'inverse, du style "j'importe le bug depuis les bts des distributions".
Et un point que j'ai oublié, c'est qu'on parle de web 2.0, de données captives, etc. Mais ce genre d'outil, c'est exactement dans l'optique des mouvements comme le DAta Liberation Front ( http://www.dataliberation.org/ ), ou finalement, si tu n'es pas content de tel ou tel presta, tu changes. Si tu veux faire des modifs à l'interface juste pour toi, tu le fait.
Peut être que ça va pas prendre, aprés tout, TLA n'a pas pris tout de suite, et n'aurait trés bien pu ne pas prendre. L'idée de dvcs, c'est que la théorisation de ce que foit la plupart des gens quand ils modifient dans leur coin un document.
Et j'aurais tendance à dire qu'au dela des bts et du code, il y a aussi une place pour un wiki distribué ( comme http://ikiwiki.info/tips/distributed_wikis/ , ou http://wiki.laptop.org/go/MikMik ).
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 1.
[^] # Re: Et la timeline ?
Posté par ZeroHeure . Évalué à 2.
C'est un gestionnaire de version décentralisé, qui décentralise tout: gestion de version, gestion des bugs, wiki, etc.
Très léger en plus. Et très très bien.
(Par l'auteur de SQLite au fait)
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et la timeline ?
Posté par Thomas C. . Évalué à 3.
[^] # Re: Et la timeline ?
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 3.
De plus c'est bien beau de rapporter upstream mais bon cela multiplie les comptes bugzilla et bon au bout d'un moment c'est lourdingue. Le fait de centraliser cela sur une seule interface c'etait a la base une bonne idee a mon avis mais vu que ubuntu est pas super populaire aupres de devs cela ete un echec globalement.
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . Évalué à 3.
http://lwn.net/Articles/321473/
( tout comme d'autres distributions, au passage ).
Quand au fait que ça multiplie les comptes, c'est certes chiant, mais la solution est à mon avis d'un autre ordre, au hasard, openid.
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 3.
un lien interessant trouve dans le tiens :)
Par contre sur mainline je connais et je m'en moque, je suis passer a autre chose que ubuntu et non je ne suis pas passe a RH/Fedora car j'utilise KDE et RH/Fedora aime toujours pas ce bureau (cela m'enerve au plus au point d'avoir tous les outils de config clickodrome en Gtk).
[^] # Re: Et la timeline ?
Posté par Ronan BARZIC . Évalué à 5.
Le 29 Mars, le gars se demande si ce n'est pas une autre manifestation d'un bug déjà connu (il poste un lien ) :
Might be upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=14430
Ensuite, vient un hack, puis le Grand Ts'o en personne
Le gars, c'est pas un expert noyau, donc je comprend qu'avant de passer pour un zozo, il prenne son temps.
D'autant que si on y regarde d'un peu plus près, il peut sembler un peu gros le bug, pour un système de fichier comme ext4 avec les pointures qui s'y sont collés
Comme quoi, ca arrive à tout le monde...
[^] # Re: Et la timeline ?
Posté par bubar🦥 (Mastodon) . Évalué à 7.
Et sur ce même évènement on peux dire que Canonical en sort en fait grandi, grâce à l'attitude cette personne. Elle a pas "pété plus haut que son cul" si vous me permettez l'expression, en ne se trompant pas de hierarchie pour lui, en posant la question ailleurs d'abord. Donc Canonical a du personnel compétents et attentifs. Pas du gros cadors partout, malheureusement pour eux (vais pas paraphraser ce qu'as dit GeneralZ un peu plus haut sur ça précis) et pour tout le monde. N'empeche que le type il s'est pas pris pour dieu le père et a fait son taf convenablement, proprement, à hauteur de ses moyens. Par cela il 'grandi' canonical (et tempère les insupportables triades de leur dictateur bienveillant).
Et puis ... faut reconnaitre que ce bug il est découvert chez ubuntu. Preuve s'il en est que ubuntu rempli son role, là : pas la distro pour entreprises certes, mais la distro la plus usitée et la plus active en terme d'utilisateurs.
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 4.
ce qui explique peut etre la reaction de T'so. Son amour propre aurait ete touche? :)
Je ne dis pas qu'il a tord mais bon la c'est un pauvre gars qui fait son boulot comme il peut qui s'en prend plein la tete. La communaute hors Ubuntu tape sur Canonical et dans Canonical le rapporteur de bug a du se faire tuer ce qui va l'inciter enormement a rapporter ce genre de bug ailleurs. La prochaine fois cela sent le bug qui va rester sur launchpad dans son coin bien au chaud. Alors certes cela criera parceque le bug avait ete decouvert sur Ubuntu et non passe aux autres mais que veux tu au moins il aura "juste" pas trie comme il faut le bug en question.
[^] # Re: Et la timeline ?
Posté par GeneralZod . Évalué à 3.
Justement, il faut attendre plus d'un mois pour que ce bogue soit rapporté upstream, et en plus le mainteneur ubuntu lâche le merdier sur le bugzilla fedora dans l'espoir que le mainteneur fedora fasse son boulot (c'est à dire aider les développeurs upstream à corriger le bogue voire le corriger lui-même si il a les compétences).
> c'est un pauvre gars qui fait son boulot
Ce serait un incident isolé, certes mais c'est un problème structurel dans Canonical. Ok, ils n'ont pas les compétences pour corriger le bogue, mais de là à se défausser de leurs responsabilités d'intégrateurs ça devient grave. Entre le mainteneur X qui est débordé par les rapports de bogues, Kees Cook qui n'a pas le temps de suivre convenablement un bogue critique dans une version LTS (et qui aurait dû probablement être un release blocker), il est urgent d'agir.
Il faut soit recruter plus de monde, soit restreindre les paquets couverts par le support et laisser plus de place à la communauté dans la gestion technique (un peu comme Fedora avant FC6 Core/Extras).
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
[^] # Re: Et la timeline ?
Posté par Albert_ . Évalué à 3.
Je vois pas pourquoi tu t'excites. La gestion des bugs par canonical/ubuntu est on ne peut plus connu. Par contre c'est aps plus mal qu'il l'ai rapporte a Fedora vu que Fedora doit sortir une version dans pas longtemps et que cette distrib est elle aussi touche.
En l'occurrence, ce n'est pas sur le seul Kees Cook qu'il faut taper, mais sur l'employeur qui ne lui permet pas de faire son boulot dans de bonnes conditions.
Et tu crois vraiment que cela va changer qq chose? La c'est juste Kees Cook qui se fait traiter d'incompetent etc donc a mon avis la prochaine fois il va se passer exactement ce que je decris c'est a dire rien. Le bug sera reference et "oh pas de bol on l'a pas vu". Cette facon d'agir est exactement la raison pour laquelle je me tape comme de ma premiere chemise des versions beta et RC (que ce soit ubuntu ou fedora d'ailleurs) car mon experience m'a montre que si un bug present et rapporte lors de la soit disant phase de test, sera present dans la version final. J'a l'impression que les devs corrigent uniquement les bugs sur lesquels ils tombent ou qui sont vraiment emmerdant comme une non harmonisation des couleurs dans le menu et j'exagere a peine c'est ca le pire. Alors ce n'est pas completement vrai pour Fedora mais uniquement parceque je connais personnellement le dev qui s'occupait des paquets qui me faisait c... Les distribs verifient en gros que les paquets s'installent comme il faut mais se moque un peu que le logiciel fonctionne ou pas.
[^] # Re: Et la timeline ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
Et si son intention n'était pas simplement d'avertir Fedora qu'il y a un bug dans leur distrib, sans forcément attendre un résultat d'eux ? (un peu genre « au fait les gars, je me suis rendu compte qu'un bug ubuntu affecte aussi votre distro, je voulais vous prévenir au cas où »).
Pourquoi supposer dès le départ la « malveillance » ?
[^] # Re: Et la timeline ?
Posté par Maclag . Évalué à -1.
Du coup il a toujours une Fedora sous la main et teste dessus.
Ne pouvant supporter l'idée que Fedora laisse passer un bug dans la version qui vient, il prévient les mainteneurs!
Comme quoi, Fedora c'est mieux qu'Ubuntu: même leurs dévs la préfèrent!
------------------>
(avec le décalage horaire, on est déjà vendredi ici!)
[^] # Re: Et la timeline ?
Posté par Misc (site web personnel) . Évalué à -1.
Surbhi est une femme, aussi hors norme que ça puisse paraitre, mais des personnes du sexe opposé codent aussi sur le kernel.
Donc je me demande comment tu fait pour savoir que c'est pas une experte noyau si tu sais déjà pas que c'est une femme :/
[^] # Re: Et la timeline ?
Posté par imr . Évalué à 2.
Tu veux dire qu'en sachant que c'est une femme on saurait alors que c'est pas un expert du noyau?
[^] # Re: Et la timeline ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.