Journal Canonical FAIL

Posté par  .
Étiquettes :
19
5
mai
2010
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
  • # Exagéré

    Posté par  (site web personnel) . Évalué à 10.

    Mouaif. Je te trouve un peu partial dans ton journal (mais en tout cas ça valait le coup d'en parler car le sujet est intéressant).

    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  (site web personnel) . Évalué à 8.

      Bon évidemment je me suis gourré dans le copier/coller du lien vers le bugzilla du noyau : https://bugzilla.kernel.org/show_bug.cgi?id=15906
    • [^] # Re: Exagéré

      Posté par  (site web personnel) . Évalué à 2.

      Visiblement, airlied a aussi quelques soucis avec la distribution Electrolux http://airlied.livejournal.com/72455.html il a dû patcher lui-même pour que ça fonctionne ;-)
    • [^] # Re: Exagéré

      Posté par  . Évalué à 9.

      > il a décidé de prévenir tout le monde.

      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  (site web personnel) . Évalué à 1.

        Perso, je trouve que la méthode choisi par canonical pour le suivi des bugs upstreams est loin d'etre propre. Il aurait fallu plutot bossé en profondeur, pour décrire un bug dans un format indépendant ( xml, json, whatever, c'est pas le propos ), et ensuite faire en sorte que les différents bugs trackers fassent un export dans ce format.

        Ç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  (site web personnel) . Évalué à 4.

          le but [était] de concurencer RH et progeny,

          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  (site web personnel) . Évalué à 5.

        >>> pourquoi ne pas l'avoir fait pour Debian (plus logique), SuSE ou Mandriva ?

        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  . Évalué à 9.

          > Peut-être qu'il n'a que ces deux distros d'installés sur sa machine ?

          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  . Évalué à 9.

            C'est quoi un DD mis à part un Disque dur ?
    • [^] # Re: Exagéré

      Posté par  . Évalué à 4.

      ...mais l'histoire sur Fedora ça me semble être du bullshit (d'après ce que j'ai vu rapidement).

      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!
  • # mouhais

    Posté par  . Évalué à 10.

    je suis le premier a dire que ubuntu fait n'importe quoi avec ses bugs et surtout rien pour les corriger. Par contre vu que le bug n'est pas specifique a eux (ce qui est d'un certain cote tres surprenant vu leur capacite a en introduire) mais au contraire present upstream c'est plutot pas mal d'avoir tente de contacter les specialistes du sujet qui sont employes chez Red-Hat.
    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  . Évalué à -5.

    Demain le monsieur propre redhatfanboy nous expliquera comment ubuntu pique les bonnes idées des fedora avant leur sortie, comment canonical cherche à voler la matière grise de red hat, comment les devs d'ubuntu piquent toutes les bonnes idées des autres distro, comment ils contribuent en secret à l'élaboration des pilotes proprios merdvidia, comment ils pervertissent l'esprit du libre, comment dans la vraie vie les contributeurs d'ubuntu/debian, travaillant dans la même structure professionnelle que ceux de fedora, filent à ces derniers des laxatifs dans leur café.

    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  . Évalué à 8.

      > comment les devs d'ubuntu piquent toutes les bonnes idées des autres distro de Mac OS X
      • [^] # Re: XLusive

        Posté par  . Évalué à 10.

        > comment les devs d'ubuntu piquent toutes les bonnes idées des autres distro de Mac OS X du Mac OS des années 80 même si elles ne sont plus tout à fait aussi pertinentes 25 ans après.

        BeOS le faisait il y a 20 ans !

    • [^] # Re: XLusive

      Posté par  . Évalué à 2.

      fedora != red hat et autre chose, j'en ai strictement rien à péter de Red Hat.

      Je ne relèverais pas les autres imbécilités.
      • [^] # Re: XLusive

        Posté par  . Évalué à -2.

        Ben y pas raison vu que la réciproque demanderait beaucoup trop de boulot.

        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  . Évalué à 6.

          Et où dit-il, aujourd'hui, que Fedora saileplusmieux ?
        • [^] # Re: XLusive

          Posté par  . Évalué à 3.

          Comparatif:

          - 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!
  • # Web 0.1

    Posté par  . Évalué à 10.

    P*tain, mais pourquoi ne pas faire des liens directement dans le texte ?
    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  . Évalué à 4.

      Rectification : les liens ne sont pas inversés, ils sont carrément dans le désordre.

      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  . Évalué à 10.

        ils sont carrément dans le désordre.
        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  . Évalué à 9.

      P*tain, mais pourquoi ne pas faire des liens directement dans le texte ?
      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  . Évalué à 3.

      cherche pas c'est la mode sur linuxfr. Les journaux sont sans doute d'abord écrits, puis documentés ensuite.
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Web 0.1

        Posté par  . Évalué à 3.

        Peut-être parce que la syntaxe n'est pas décrite ?

        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  . Évalué à 1.

          * comme précisé dans l'aide, la balise html a n'est pas autorisée.
          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  . Évalué à 6.

            Faut le noter pour la prochaine version en Ruby.

            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  . Évalué à 3.

              Pas de problème, vu qu'à la base je suis fondamentalement d'accord avec toi. :o)
          • [^] # Re: Web 0.1

            Posté par  . Évalué à 7.

            <a> est justement autorisé pour le corps des journaux, comme précisé dans l'aide.
      • [^] # Re: Web 0.1

        Posté par  (site web personnel) . Évalué à 7.

        Peut-être parce que la syntaxe n'est pas décrite ?

        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  . Évalué à 2.

          Ça fait longtemps que j'ai pas écrit un journal, j'aurais du relire l'aide plutôt que de supposer que c'est le même paragraphe que les commentaires.
          Je m'en souviendrais pour le prochain journal "xxxxx FAIL" (qui portera sur une autre distribution)
          • [^] # Re: Web 0.1

            Posté par  . Évalué à 2.

            (qui portera sur une autre distribution)

            Non non, je ne crois pas :)
        • [^] # Re: Web 0.1

          Posté par  . Évalué à 2.

          Et rajouter ça dans les "conseils" avant de poster, c'est pas possible ?
          • [^] # Re: Web 0.1

            Posté par  (site web personnel) . Évalué à 2.

            ça y est déjà, tu peux le vérifier sur http://linuxfr.org/journal/new.html ; simplement, comme le dit GeneralZod, ce n'est pas la même chose pour les commentaires, donc forcément ça prête à confusion :/
            • [^] # Re: Web 0.1

              Posté par  . Évalué à 2.

              Un truc con mais un petit lien sur une page de ton wiki dans les conseils pour les commentaires et les journaux ca couterait pas cher et ca éviterait de tout dupliquer.
  • # Bof

    Posté par  (site web personnel) . Évalué à 10.

    On leur rapporte un bug, ils le qualifient, le bug n'est pas chez eux mais sur le projet source, ils diffusent l'info et tentent de faire corriger par les gens qui savent.

    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  (site web personnel) . Évalué à 10.

      >>> '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

      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  . Évalué à 3.

        Ca d'accord mais c'est un autre problème.

        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  . Évalué à 7.

          Avec un discours comme le tien, on se demande pourquoi ils n'ont pas un dev Gnome, et un pour chaque appli....

          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  (site web personnel) . Évalué à 3.

            Oui mais c'est également vrai qu'il s'agit là d'un comportement d'une personne. Donc c'est vrai que la manière trollesque de présenter l'évènement (que j'adore :p ) c'est exagéré. Auriez vous préféré que la personne ai fait ce post sur le bugzilla du projet directement ? Peut être que cette personne a juger judicieux par rapport à ses connaissances du sujet de soumettre en premier lieu à redhat (heu pardon, fedora) afin de voir ce que fedora en pense et de le reporter au projet ensuite ou de laisser fedora faire selon son choix. Sur cet acte réel et bien concret, effectivement cela découvre ubuntu (heu pardon canonical) comme n'ayant pas les compétences recquises sur le sujet, mais peut être que cette personne au final a eu raison de procéder ainsi ? Pourquoi reporter au projet si ce n'est pas assez précis, avec des pistes de solutions voir mieux, et si cela ne puisse être fait sur un terme plus long qu'un seul rapport ? On peux voir le même évènement comme quelque chose de positif, du moins pour la personne chez canonical qui a procédé ainsi.
            non ?
            • [^] # Re: Bof

              Posté par  . Évalué à 7.

              Non, vraiment, c'est naze. On peut ce cacher derrière du "c'est plus rapide en faisant comme ça", etc... c'est naze.

              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  (site web personnel) . Évalué à 3.

                C'est Kees Cook le rapporteur du bug chez Ubuntu qui l'a rapporté chez Fedora.
                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  . Évalué à 1.

                Tu ne peut pas te revendiquer comme la distrib LEADER dans le monde de Linux et se comporter comme un vampire.
                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  . Évalué à 6.

      Je ne leur reproche pas de ne pas savoir corriger tout les bogues mais que la collaboration se fasse un peu trop à sens unique.
      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  . Évalué à 2.

        En fait, si tu creuse un peu, certains à l'origine de ext4 sont chez RedHat
        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  . Évalué à 2.

          > certains à l'origine de ext4 sont chez RedHat
          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  . É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é).


            Pour des question de kernel? J'ai comme un enorme doute sur le coup...
            • [^] # Re: Bof

              Posté par  . Évalué à 2.

              Peut-être pas sur ce paquet, mais le groupe kernel-maintainers comporte quelques membres de la communauté, et tous ne sont pas des kernels hackers et encore moins sont des spécialistes de ext4. Rien ne garantit que tu tireras le bon numéro quand à savoir qui s'occupera du ticket.
              • [^] # Re: Bof

                Posté par  . Évalué à 5.

                Donc sachant que le bug ne pourra pas etre reproduit sur une RHEL vu l'age du dernier kernel dessus et pas de ext4 il me semble, mettre le bug sur Fedora semble plus logique meme si il aurait du etre mis upstream. En meme temps upstream s'occupe plus specialement de 2.6.34 et celui en charge de la maintenance du noyau 2.6.32 aime Canonical autant que toi... donc bon le gars de Canonical a tente et je pense pas qu'il le refera.

                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  . É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 ?
      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  . Évalué à -2.

      Sauf que la méthode utilisée est assez détestable et irrespectueuse ...

      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  (site web personnel) . Évalué à 6.

        >>> Le bugzilla de Fedora est là pour rapporter et traiter les bogues rencontrés par les utilisateurs de Fedora.

        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  . Évalué à -4.

          Mais est-ce que ça affecte un UTILISATEUR réel de Fedora ? La question est là.
          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  (site web personnel) . Évalué à 10.

    Un point qui me choque, c'est ça :

    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  . Évalué à 4.

      Mais bon, le fait de pas l'avoir rempli upstream plus tot me laisse perplexe.

      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  (site web personnel) . Évalué à 4.

        La soumission automatisé vers l'upstream est à mon avis complexe à faire. Je pense vraiment qu'on devrait s'orienter vers une espéce de git pour la gestion des bugs ( cf SD, comme dit plus haut, et qui va être présenté lors des rmll : http://2010.rmll.info/Gestion-de-bugs-peer-to-peer-avec-SD-e(...) ).

        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  . Évalué à 3.

          J'avoue que j'ai un peu de mal à comprendre l'intérêt d'un bugtracker distribué.

          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  (site web personnel) . Évalué à 3.

            C'est facile. Tu prends tout ce que tu peux faire avec un systéme distribué de gestion de sources, et tu appliques.

            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  . É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  . Évalué à 2.

                Il ne faut pas oublier que toutes les distribs patchent les logiciels qu'elles distribuent et donc il y a potentiellement des bugs spécifique à la distrib. C'est donc logique de localiser la source du bug avant de le pousser upstream, et il peut être intéressant de garder l'historique.

                « 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  (site web personnel) . Évalué à 2.

                ça existe deja :

                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  . Évalué à 1.

                  l'idee a l'air pas mal mais putain du perl... et que c'est @!#!$$!@# a installer sans etre root (en fait je n'y suis pas arrive mais je connais rien de rien a perl donc il doit y avoir une methode le probleme c'est laquelle...). Il y a aussi le fait qu'il faille changer un flag sur /tmp.
          • [^] # Re: Et la timeline ?

            Posté par  (site web personnel) . Évalué à 2.

            Alors jette un oeil à Fossil http://www.fossil-scm.org/
            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  . Évalué à 3.

      Mais tu n'as pas fini de critiquer Canonical ? Tu n'as pas compris que c'était mal vu de dire ce que tu pensais ? Misc, reprend le droit chemin !
    • [^] # Re: Et la timeline ?

      Posté par  (site web personnel) . Évalué à 2.

      Notes que le fait de ne pas avoir rempli l'upstream plus tôt on peut aussi le reprocher au rapporteur initial du bug. (ça n'empêche pas ta remarque d'être très pertinente ceci dit)
      • [^] # Re: Et la timeline ?

        Posté par  . Évalué à 3.

        Ouhais enfin rapporter un bug kernel upstream surtout lorsque tu viens de ubuntu c'est une tres mauvaise idee et d'ailleurs deconseille lors du demarrage car le kernel a ete "legerement" tainted par ubuntu.

        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  (site web personnel) . Évalué à 3.

          En même temps, ça fait 1 an qu'il est possible de prendre un kernel non modifié :
          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  . Évalué à 3.

            http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/200(...)

            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  . Évalué à 5.

      Faut pas pousser mémé dans les orties quand même
      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  (site web personnel) . Évalué à 7.

        Vivi
        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  . Évalué à 4.

        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

        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  . Évalué à 3.

          > Alors certes cela criera parceque le bug avait ete decouvert sur Ubuntu et non passe aux autres

          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  . Évalué à 3.

            un bogue critique dans une version LTS (et qui aurait dû probablement être un release blocker)

            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  (site web personnel) . Évalué à 5.

            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).

            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  . Évalué à -1.

              Et si en fait il adooooore Fedora mais il est payé par Canonical.
              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  (site web personnel) . Évalué à -1.

        S/le gars/la fille/

        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  . Évalué à 2.

          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
          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  (site web personnel) . Évalué à 4.

          Sauf qu'il parle de Kees Cook et pas de Surbhi. Il faut suivre un peu.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.