Journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur

Posté par (page perso) . Licence CC by-sa
44
23
déc.
2012

Peuple de LinuxFr, l'heure est grave.

Alors que ploum trolle sans vergogne sur l'intégrisme de la FSF, des critiques bien plus concrètes, informées et graves se font jour en ce mois de décembre.

D'abord, le 10 décembre, Nikos Mavrogiannopoulos annonce que le projet GnuTLS quitte l'égide de GNU après 12 ans. En cause, « un désaccord majeur avec les décisions et pratiques de la FSF ». Le site LWN a publié un article sur le sujet cette semaine, chroniquant cette tentative de sécession et les problèmes de la cession des droits imposée par la FSF pour les projets GNU. En effet, la réponse acerbe a été rapide et acerbe : en bref, le copyright nous appartient et on t'emmerde. Néanmoins, pas de requête formelle de changer le nom, peut-être selon LWN parce que — même s'il a transféré ses droits patrimoniaux — Mavrogiannopoulos est l'auteur principal de GnuTLS et peut se prévaloir d'un droit moral sur le nom.

Nouveau coup de tonnerre samedi 22, quand Paolo Bonzini annonce qu'il démissionne de ses fonctions de mainteneur de GNU sed pour des raisons similaires. Il en liste trois :
- le seul moyen d'avancer pour un projet (GNU) est d'ignorer les recommandations de la FSF (inutiles, voire nocives car immobilistes),
- GNU n'apporte plus rien à la FSF, et surtout la FSF ne soutient plus assez GNU (en particulier financièrement),
- être étiqueté GNU ne rend plus un projet attractif de nos jours, bien au contraire.

Le débat fait déjà rage ailleurs, en particulier sur Hacker News où un précédent mainteneur de sed corrobore les critiques formulées par Bonzini et critique en particulier les compétences techniques de… Richard Stallman .

Et toi, peuple de LinuxFr, en cette avant-veille de Noël, penses-tu qu’il faille faire la trêve, ou au contraire souhaiter la mort de GNU, « étouffé de dinde aux marrons » ?

  • # Ce n'est pas ce qu'il dit.

    Posté par . Évalué à  10 .

    critique en particulier les compétences techniques de… Richard Stallman .

    C'est faux. Il dit que Stallman était, et est probablement toujours, un programmeur brillant, malgré son âge :

    If you were working on a program and sought his advice, he was very good at zeroing in on the issues and giving excellent advice. And sometimes if you were working on a program and he noticed something he didn't like about your approach, his criticisms were very good. People used to tell stories about how good a programmer he was and those stories were basically all true. He was sharp and I assume that, in spite of his age, he still is.

    Par contre, il estime qu'il est nul comme leader de projet (sans doute parce qu'il n'est pas assez "sociable") :

    RMS's technical leadership was, I think, not very skilled. […] The problem was that he showed no effective capacity to really lead the larger meta project of pulling together a complete OS. […] The RMS failure I see is a failure at being a community organizer of GNU programmers.

    • [^] # Commentaire supprimé

      Posté par . Évalué à  10 .

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

      • [^] # Re: Ce n'est pas ce qu'il dit.

        Posté par . Évalué à  0 .

        Tu te chopes un -2 avec un commentaire tout ce qu'il y a de constructif… Qu'est-ce que tu as fait ? Tu as insulté un sorcier africain ? Il t'a jeté un sort ?

    • [^] # Re: Ce n'est pas ce qu'il dit.

      Posté par (page perso) . Évalué à  -1 .

      La gestion de projet, c'est aussi une compétence technique hein.

      • [^] # Re: Ce n'est pas ce qu'il dit.

        Posté par . Évalué à  10 .

        C'est avant tout une gestion de ressource humaine et social. On l'oublie bien souvent en faisant des jolis diagrammes de planification…

        • [^] # Commentaire supprimé

          Posté par . Évalué à  3 .

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

        • [^] # Re: Ce n'est pas ce qu'il dit.

          Posté par (page perso) . Évalué à  0 .

          Puis surtout ce n'est pas la même technique, il y a un monde entre les techniques d'informatiques, maths et compagnie, les techniques de gestion de projet, gestion de l'humain ou social et les techniques d'autres domaines (comme des techniques artistiques).

          RMS est bon en info et en maths de part sa formation, en humain et gestion de projet on n'a vu mieux. Je pense même qu'il vaut mieux laisser des gens non informaticiens gérer des projets informatiques plutôt que de mettre aux mains d'informaticiens des techniques qu'ils maitrisent mal (et souvent n'aiment pas d'ailleurs).

          • [^] # Re: Ce n'est pas ce qu'il dit.

            Posté par (page perso) . Évalué à  10 .

            Je pense même qu'il vaut mieux laisser des gens non informaticiens gérer des projets informatiques plutôt que de mettre aux mains d'informaticiens des techniques qu'ils maitrisent mal (et souvent n'aiment pas d'ailleurs).

            Je ne compte plus le nombre de désastre que j'ai rencontré dans ma vie professionnelle comme informaticien du fait de mettre la gestion de projet dans les mains de non informaticien. C'est pour moi la plus grande cause des échecs du génie (Quel mot à la con) logiciel.

            Pour quoi ça foire ? Parce qu'on ne vend pas des petits pois, pardi ! Le développement c'est toujours de la recherche et du développement (oui le département qui n'existe quasi plus dans les boîtes Européennes). Dans aucun autre domaine (physique, chimie, …), on aurait l'idée farfelue de mettre dans les mains d'un marketeux ou mba quelconque la charge du projet. Comment un ignorant en informatique est-il capable de trouver un équilibre entre la qualité, les coûts et les délais s'il n'a aucune idée de ce que cela signifie dans ce contexte bien précis.

            Voici, une des parties des grosses conneries que je vois tous les jours :

            • Ajouter plus de personnes sur un projet en retard [1]
            • Composer des équipes gigantesques (on sait trivialement que la communication augmente comme n*(n-1)/2 [1])
            • Compter le nombre de ligne de code, compter les secondes passées à coder, documenter, à aller à la toilette, boire du café, … comme métriques de la productivité
            • Éviter les « stars », il faut du personnel interchangeable. Il faut absolument éviter les gens meilleurs que les autres. Donc, on tend vers la médiocrité.
            • Faire de superbes cascade en prétendant faire la méthodologie RUP combinée avec PRince2 agile et certifié CMMi 52.36 et iso 9001 (par exemple, suivre à la lettre [2])
            • Obliger l'utilisation de l'éditeur XYZ et de pleins de techno « in »

            [1] The mythical man-month
            [2] How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering

            • [^] # Re: Ce n'est pas ce qu'il dit.

              Posté par (page perso) . Évalué à  2 . Dernière modification : le 23/12/12 à 23:50

              Je ne compte plus le nombre de désastre que j'ai rencontré dans ma vie professionnelle comme informaticien du fait de mettre la gestion de projet dans les mains de non informaticien. C'est pour moi la plus grande cause des échecs du génie (Quel mot à la con) logiciel.

              Attention, je l'ai dit dans cette page, pour moi un projet ça devrait se gérer à deux : celui qui gère l'aspect technique du bousin (l’architecture, les outils, découper les étapes, etc.) et celui qui va plutôt gérer l'humain, le client, la hiérarchie, les éventuels fournisseurs, etc. C'est pour moi l'idéal pour avoir un projet bien géré.

              Car soyons honnêtes, des techniciens qui gèrent le projet ça peut souvent échouer aussi car il ne sait pas gérer l'humain et l'aspect social de la gestion (et la paperasse) et souvent d'ailleurs il n'aime pas faire ça (du coup il le fera mal).

              Ce que tu cites plus loin est vrai, et je pense justement qu'en mettant une gestion avec cette double compétence ça va mieux.

              ÉDIT : d'ailleurs je le vois en école d'ingé, tu as ceux qui préfèrent la gestion du projet et de l'humain plutôt que la technique (et sont d'ailleurs plutôt mauvais dans les matières techniques) et tu as l'inverse, ceux qui préfèrent la technique plutôt que les matières humaines. Je n'ai jamais vu quelqu'un qui aimer réellement les deux aspects de la chose de manière similaire.

              • [^] # Re: Ce n'est pas ce qu'il dit.

                Posté par (page perso) . Évalué à  6 .

                Car soyons honnêtes, des techniciens qui gèrent le projet ça peut souvent échouer aussi car il ne sait pas gérer l'humain et l'aspect social de la gestion (et la paperasse) et souvent d'ailleurs il n'aime pas faire ça (du coup il le fera mal).

                WoW, le mythe de l'asocial boutonneux. Je pensais plus qu'il existait celui-là.

                Car soyons honnêtes, des techniciens qui gèrent le projet ça peut souvent échouer aussi

                Oui, cela peut échouer mais avec une probabilité extrêmement moindre que si le gars ne connaît pas la technique.

                Je n'ai jamais vu quelqu'un qui aimer réellement les deux aspects

                Tu verras cela vient avec l'âge. Quand tu auras eu pendant 10 ans des managers qui prennent des décisions arbitraires sur des sujets qu'ils ne connaissent pas et qu'ils n'ont aucune envie d'apprendre (ils s'en foutent, ils changent de jobs au max tous les 2 ans et n'arrivent jamais à la clôture du projet), tu comprendras que tu ne veux plus jamais être en-dessous de ces gens.

                • [^] # Re: Ce n'est pas ce qu'il dit.

                  Posté par (page perso) . Évalué à  3 . Dernière modification : le 24/12/12 à 01:05

                  PS : Je ne suis pas sur que ce soit de l'amour de la gestion de projet que tu auras gagné après 10 ans de travail. Tu auras simplement appris à haïr l'informatique pro que tu préféreras largement la gestion de projet et le management.

                • [^] # Re: Ce n'est pas ce qu'il dit.

                  Posté par (page perso) . Évalué à  6 .

                  WoW, le mythe de l'asocial boutonneux. Je pensais plus qu'il existait celui-là.

                  Je ne dis pas que le technicien est asocial, mais que de gérer de l'humain, la paperasse, la hiérarchie, la clientèle and co il n'en voulait souvent pas ou qu'il n'était pas formé pour ces tâches là mais pour de la réalisation technique.

                  Être social ne te rend pas apte à gérer des problèmes humains, juste à t'intégrer dans un groupe, c'est très différent.

                  • [^] # Re: Ce n'est pas ce qu'il dit.

                    Posté par . Évalué à  4 . Dernière modification : le 24/12/12 à 13:04

                    C'est marrant parce que dans mon parcours j'ai vu autant de techos mauvais chef de projet (ou mauvais manager), que de chefs de projets incompétents parce que pas assez technique.

                    Un chef de projet peut très bien gérer un projet sans être un expert technique : il lui faut juste avoir suffisamment de vernis technique pour comprendre ce que ses équipes lui disent, et surtout ne pas avoir trop d'égo et faire confiance aux gens avec qui ils travaillent. C'est la même chose pour le chef de projet issu du technique : bienj souvent ceux qui ne savent pas gérer ont un problème d'égo, et n'ont pas l'envie de lacher la technique.

                • [^] # Re: Ce n'est pas ce qu'il dit.

                  Posté par . Évalué à  8 .

                  Car soyons honnêtes, des techniciens qui gèrent le projet ça peut souvent échouer aussi car il ne sait pas gérer l'humain et l'aspect social de la gestion (et la paperasse) et souvent d'ailleurs il n'aime pas faire ça (du coup il le fera mal).

                  WoW, le mythe de l'asocial boutonneux. Je pensais plus qu'il existait celui-là.

                  Ne pas savoir gérer l'humain ce n'est pas être associable, c'est une compétence en soit. Faire correspondre autant que possible les envies et compétences des développeurs aux besoins et contraintes du développement si c'était simple ça se saurait.

                  Tu verras cela vient avec l'âge. Quand tu auras eu pendant 10 ans des managers qui prennent des décisions arbitraires sur des sujets qu'ils ne connaissent pas et qu'ils n'ont aucune envie d'apprendre (ils s'en foutent, ils changent de jobs au max tous les 2 ans et n'arrivent jamais à la clôture du projet), tu comprendras que tu ne veux plus jamais être en-dessous de ces gens.

                  Tu devrais surtout changer de boite. Il y en a où le projet est géré par 3 responsables :

                  • le chef de projet qui organise les tâches de chacun
                  • le leader technique qui est responsable des choix techniques du projet
                  • le directeur de projet qui s'occupe de la partie relation client

                  et un truc bien c'est que le chef de projet n'est pas ton chef !

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: Ce n'est pas ce qu'il dit.

                    Posté par (page perso) . Évalué à  4 .

                    Ne pas savoir gérer l'humain ce n'est pas être associable, c'est une compétence en soit. Faire correspondre autant que possible les envies et compétences des développeurs aux besoins et contraintes du développement si c'était simple ça se saurait.

                    (asocial pas associable, on ne fait pas de la théorie des ensembles :/ )

                    Premièrement, j'airépondu à « car il ne sait pas gérer l'humain et l'aspect social de la gestion ». Tu te fixes sur la première partie du « et » alors que je réponds principalement à la seconde. Il serait bien de ne pas déformer mon propos.

                    Deuxièmement, si on reprend la définition de « social » :

                    sociable /sɔ.sjabl/ masculin et féminin identiques
                    
                    - Qui est naturellement porté à rechercher la société, qui est destiné à vivre en société.
                    - Avec qui il est facile de vivre, qui est d’un bon et facile commerce.
                    - Qui porte vers les autres.
                    
                    

                    Ne pas savoir gérer l'humain ce n'est pas être associable

                    Comment peut-on à la fois ne pas être capable de gérer l'humain et être sociable (vivre en société, par exemple dans une équipe projet) ? Si on est capable de gérer l'humain est trivialement sociable et si on est sociable, on est capable de gérer l'humain. On ne peut avoir l'un sans l'autre.

                    Je ne comprends pas cette opposition systématique entre le technique et le non-technique. La gestion de l'humain et vivre en société n'est pas une option peu importe le fait d'être technique ou pas. La sociabilité dans une équipe n'est pas une option, c'est un requis. Le chef de projet n'est qu'un membre de l'équipe comme les autres. La seule différence c'est qu'il doit à la fois connaître les us et coutumes (vocabulaire) des techniques et des non-techniques (qui sont souvent finalement des techniques mais dans un autre domaine). C'est pour ça qu'il doit être le plus polyvalent de l'équipe et avoir beaucoup d'expérience.

                    Tu devrais surtout changer de boite. Il y en a où le projet est géré par 3 responsables :
                    le chef de projet qui organise les tâches de chacun
                    le leader technique qui est responsable des choix techniques du projet
                    le directeur de projet qui s'occupe de la partie relation client

                    WoW, l'hyper-spécialisation ! C'est justement un des problèmes majeurs que j'ai rencontré et que j'ai cité indirectement dans « Composer des équipes gigantesques (on sait trivialement que la communication augmente comme n*(n-1)/2) ».

                    Une des caractéristiques principale des projets informatiques c'est l'interdépendance de tous les domaines qui le compose. Il est impossible de séparer les choix techniques, des délais, des coûts et de la relation client. Par exemple, les choix techniques dépendent de la relation client et ont des conséquences sur les délais et les coûts. En multipliant, les personnes ont accroît quadratiquement la communication. On se retrouve rapidement à avoir un « directeur de projet » qui n'est qu'un commercial et essaie de vendre des « changements », un leader technique qui se distancie du client, un chef de projet qui balance des tâches uniquement fonctionnelles peu importe les implications sur les domaines des autres : « ce n'est pas leur job ».

                    • [^] # Re: Ce n'est pas ce qu'il dit.

                      Posté par . Évalué à  1 .

                      Je ne comprends pas cette opposition systématique entre le technique et le non-technique.

                      Je me suis arrêté de lire à cette phrase. Je n'ai en aucun cas opposé le technique et le non-technique, j'ai juste dis que la diplomatie et tout ce qui va avec tout le monde n'est pas bon pour ça et tout le monde n'a pas forcément envie d'en faire son métier.

                      WoW, l'hyper-spécialisation !

                      Non c'est juste des compétences différentes c'est donc reconnu comme tel (mais ça dépend de la taille des projets).

                      En multipliant, les personnes ont accroît quadratiquement la communication.

                      On multiplie pas, on ajoute. Je ne sais pas ce que c'est qu'augmenter la communication. Mais vraiment je ne sais pas où tu bosse (et je m'en fou un peu) mais si là où tu travail vous êtes en vase clos et il ne peux pas y avoir de dialogue entre 3 personnes vous avez un gros problème qui n'est pas lié à la technicité ou non des chefs de projets. En pratique on ne vend rien au client sans l'avale des 3 que j'ai cité. On arrive à être suffisamment réactif et les techniciens sont en contacte directe avec le client pour la définition des besoins, lors de la réalisations et lors de la recette du logiciel.

                      Après souvent le chef de projet est un ancien développeur (je n'ai pas dis que ce n'était pas possible juste que les développeurs ne font pas forcément de bons chef de projet).

                      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                      • [^] # Re: Ce n'est pas ce qu'il dit.

                        Posté par (page perso) . Évalué à  2 .

                        (je n'ai pas dis que ce n'était pas possible juste que les développeurs ne font pas forcément de bons chef de projet).

                        Mais quelqu'un qui ne connaît rien au développement n'est jamais un bon chef de projet informatique.

                        Non c'est juste des compétences différentes c'est donc reconnu comme tel

                        Parce que les gens n'ont qu'une compétence ? C'est de l'hyper-spéciliasation quand une spécialité/compétence devient le job unique d'une seule personne. Ici, c'est bien le cas.

                        On multiplie pas, on ajoute. Je ne sais pas ce que c'est qu'augmenter la communication.

                        Cfr. The mythical man-month [1]. Ce que tu décris ressemble furieuse à une structure de gestion matricielle (ou du moins partiellement cela http://en.wikipedia.org/wiki/Matrix_management). Pourquoi cela foire-t'il, en version longue [4][5][2][3], en résumé :

                        structure matricielle

                        Je t'invite à lire :

                        [1] The mythical man-month http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959 . Celui qui se dit Cdp et qui ne connaît pas n'est pas un cdp (c'est mon avis personnel mais il faut n'avoir jamais lu le moindre livre de gestion de projet pour ne pas le connaître et donc être un incompétent - il y en a un paquet dans les cdp)
                        [2] http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X pour comprendre quels sont les facteurs principaux d'échec des projets.
                        [3] Je ne suis pas un grand fan de RUP mais je trouve l'article suivant fantastique : How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Si tout chef de projet pouvait le lire, cela ferait du bien à tout le monde.
                        [4] How Hardwired Is Human Behavior? pas de la gestion de projet tout à fait mais cela est plus que lié
                        [5] Changing the It Leader's Mindset: Time for Revolution Rather Than Evolution. Intéressant mais moins que les précédents, je trouve.

                        • [^] # Re: Ce n'est pas ce qu'il dit.

                          Posté par . Évalué à  1 .

                          Parce que les gens n'ont qu'une compétence ?

                          Non; La plupart des développeurs ont aussi largement les compétences nécessaires pour récurer les chiottes. Tu va donc leur demander de nettoyer les chiottes ?

                          Il y en a qui accepteront … surtout si tu paye en conséquence.

          • [^] # Re: Ce n'est pas ce qu'il dit.

            Posté par . Évalué à  3 .

            RMS est bon en info et en maths de part sa formation, en humain et gestion de projet on n'a vu mieux.

            Au contraire ;)

      • [^] # Re: Ce n'est pas ce qu'il dit.

        Posté par (page perso) . Évalué à  7 .

        Heuuu complètement pas d'accord. Les deux sont complètement dissociés.
        On peut être très bon technique et mauvais pour gérer un projet.
        Comme on peut être un très bon chef de projet et n'avoir aucune notion technique.

        • [^] # Re: Ce n'est pas ce qu'il dit.

          Posté par (page perso) . Évalué à  6 .

          Je plussoie entièrement avec ça. D'ailleurs j'ai déjà eu écho d'études mettant en évidence que les pays nordiques et anglo-saxons pensent qu'un manager ne doit pas forcément être aussi bon techniquement que les personnes qu'ils gèrent. Tout le contraire des pays « sudistes » comme la France.

          Personnellement je pense qu'il faut plusieurs personnes pour gérer les projets, la personne qui doit gérer le projets (et du coup les hommes en dessous et au dessus de lui) ne doit pas avoir de réelles compétences techniques pour le projet en cours. Cependant il faut une personne bonne techniquement pour gérer l'avancement technique (l'architecture notamment de l'ensemble). Croire qu'une personne peut gérer (et aimer) tous ces aspects efficacement, cela me semble utopique.

          • [^] # Re: Ce n'est pas ce qu'il dit.

            Posté par (page perso) . Évalué à  9 .

            Tout le contraire des pays « sudistes » comme la France.

            C'est surtout que pour une SSII, si tu t'épanouis comme bon technicien, tu vas :

            • bosser plus vite : ils s'en foutent, ils ont 50% d'effectifs destinés à gérer les dépassements
            • bosser mieux : là c'est carrément nocif, comment tu vends de la TMA après ?

            Alors que si tu écoutes religieusement ton "ingé" commercial qui t'explique ton "plan de carrière" (tu croyais décider toi-même de ta propre vie ??) et que tu "évolues" (pauvre Darwin) vers du management… il va te payer 20% plus cher mais te facturer 100% plus.

            Alors bon, c'est valable que pour les SSII. Mais c'est qui le fleuron de l'industrie informatique française ?

            Bull.

          • [^] # Re: Ce n'est pas ce qu'il dit.

            Posté par (page perso) . Évalué à  0 .

            Tout à fait. Je suis chef de projet et je suis clairement le plus mauvais codeur de mon équipe. Mais c'est peut-être parce que je bosse pour une boite allemande.

            • [^] # Re: Ce n'est pas ce qu'il dit.

              Posté par (page perso) . Évalué à  4 .

              « le plus mauvais codeur de l'équipe » != « aucune notion technique ». Je n'ai vu personne dans les commentaires dire qu'il faut que le chef de projet soit le meilleur au niveau technique mais qu'il comprenne bien comment ça fonctionne.

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Ce n'est pas ce qu'il dit.

          Posté par . Évalué à  3 .

          Comme le savoir faire d'un chirurgien est complètement dissocié des compétences techniques utilisées en informatique. Pourtant je n'irai pas jusqu'à dire que les chirurgien n'ont aucune compétence technique. Savoir gérer un projet, c'est une compétence technique, dans le domaine de la gestion de projet.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

          • [^] # Re: Ce n'est pas ce qu'il dit.

            Posté par (page perso) . Évalué à  4 .

            Tu mélanges deux activités. Si tu devais faire un comparatif dans le milieu médical, tu prendrais soit le chef de service, soit le responsable administratif.

            Dans d'autres secteurs: A priori, un réalisateur peut ne pas connaitre l'optique d'une caméra. Dans le monde du jeu-vidéo, un chef de projet peut ne pas savoir comment les shaders ont été codés. Un architecte peut ne pas savoir comment faire un enduit. Un designer automobile comment on fait pour paramétrer une tourneuse fraiseuse.

            L'important pour un chef de projet, c'est d'être cohérent et d'avoir un fil conducteur pertinent pendant tout le processus.
            Chacun son métier; mais rien n'empêche intellectuellement parlant de vouloir savoir comment cela marche.

            • [^] # Re: Ce n'est pas ce qu'il dit.

              Posté par . Évalué à  1 .

              L'important pour un chef de projet, c'est d'être cohérent et d'avoir un fil conducteur pertinent pendant tout le processus.

              Et ça, c'est sa… technique.

              Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: Ce n'est pas ce qu'il dit.

                Posté par (page perso) . Évalué à  1 .

                Mouais… Utilisation d'une méthode rhétorique afin d'avoir raison. (aka "le coup de l'entourloupette lexicale")
                Tu sais très bien qu'on parle ici de "compétences techniques informatiques ou de développement", et non "de compétences techniques de gestions (de projets)".
                Bien tenté :)

                Note d'intervention:
                L'art d'avoir toujours raison, Arthur Schopenhauer

                • [^] # Re: Ce n'est pas ce qu'il dit.

                  Posté par . Évalué à  2 .

                  Ou alors c'est toi qui n'a pas suivi le fil depuis le début.

                  La gestion de projet, c'est aussi une compétence technique hein.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                  • [^] # Re: Ce n'est pas ce qu'il dit.

                    Posté par (page perso) . Évalué à  2 .

                    A priori, on évoque RMS et le fait que pour certains le fait d'avoir des compétences techniques vaut gage de qualité pour pouvoir gérer une équipe technique et un projet.

                    Ceci dit, en relisant nos échanges, je viens de m'apercevoir qu'on ne parlait pas de la même chose.
                    Tu évoques - si je me trompes pas - le fait qu'un gestionnaire de projet utilise sa "technicité" ou "ses méthodes" afin de gérer un projet (donc à des compétences techniques de gestion);
                    Alors que moi j'évoque le fait qu'un gestionnaire de projet peut n'avoir aucune compétence technique (donc de développement) liée à la fabrication du produit au sein de son projet (ex: chef de projet / développeurs); C'est donc pour cela que je donnais les exemples ci-dessus: Hideo Kojima peut très bien être un cancre en développement et n'avoir aucune envie de savoir comment cela marche, cependant il sait bien gérer sa barque et ses projets.

                    On en revient au débat initial à propos de RMS: il peut très bien être un excellent développeur mais un piètre gestionnaire de projet. Cela n'enlève rien à ses compétences intrinsèques néanmoins, mais permet de relativiser certaines choses sur lui.

            • [^] # Re: Ce n'est pas ce qu'il dit.

              Posté par . Évalué à  6 .

              Il est quand même nécessaire qu'un chef de projet s'intéresse aux problèmes des gens qu'il encadre. Il faut parfois comprendre un minimum les problèmes, c'est tout a fait possible d'obtenir des informations d'un programmeur pour sentir la gravité d'un problème et trouver qui peut le résoudre.

              J'ai rencontré des chefs de projets qui faisaient tout une affaire d'un simple oubli lors d'une répétition parce qu'ils n'arrivaient pas à maîtriser la facilité de correction définitive alors qu'un petit problème ne pouvant en fait pas être corrigé ne les inquiétait pas.

              Je me rappelle une migration de système d'info. J'avais présenté le scénario à la personne habituellement chargée des maintenances en tête à tête. Il m'avait fait part de plein de choses intéressantes et m'avait alerter sur des problèmes potentiels. J'étais arrivé tard sur le projet et bizarrement personne avant moi ne l'avait consulté.

              Parfois, l’intérêt du dialogue, c'est juste de forcer l'interlocuteur à présenter clairement ses idées. Plus les choses sont complexes, plus je me méfie. Si l'on a la chance d'avoir des utilisateurs "sympa", on peut les faire réfléchir à leur demande et parfois la simplifier. Ca peut être simplement une colonne dans un état qui demande beaucoup de traitement ; en expliquant à l'utilisateur la difficulté, il peut s'avéré que la colonne n'est finalement pas indispensable. A contrario on peut proposé d'autres choses que l'utilisateur n'avait pas osé demander.

              Il me semble qu'une des qualités nécessaire est de faire la synthèse entre les utilisateurs et les développeurs et de faire partager les difficultés des uns et des autres. Un développeur sera plus efficace s'il se sent écouté et si on essaye de lui facilité la vie. De même un utilisateur sera plus conciliant s'il sent que l'on s'intéresse à son boulot.

              • [^] # Re: Ce n'est pas ce qu'il dit.

                Posté par . Évalué à  5 .

                Si l'on a la chance d'avoir des utilisateurs "sympa", on peut les faire réfléchir à leur demande et parfois la simplifier. Ca peut être simplement une colonne dans un état qui demande beaucoup de traitement ; en expliquant à l'utilisateur la difficulté, il peut s'avéré que la colonne n'est finalement pas indispensable. A contrario on peut proposé d'autres choses que l'utilisateur n'avait pas osé demander.

                Tu as raison… et c'est tout le principe de l'agilité.

                Pisser des specs 6 mois avant. Puis pisser des designs et des archis sur les specs 3 mois avant etc. ca fait juste une éternité qu'on sait que ça ne marche pas. Franchement chefs de projet ou architecte 90% du temps c'est de la fumisterie qui coute et ne sert à rien.

                • [^] # Re: Ce n'est pas ce qu'il dit.

                  Posté par . Évalué à  1 .

                  Tout dépend de l'architecte ou du chef de projet. On tombe parfois sur des gens qui se contente de transférer des mails des utilisateurs sans se préoccupé des contraintes techniques et des contraintes fonctionnelles. Dans ce cas, c'est sur que l'on va à la catastrophe.
                  A contrario, on arrive souvent à des modifications astucieuses et rapide qui rendent les programmes non maintenable au bout d'un certain temps.
                  Il ne faut pas oublier que certain se contente de faire ce que l'on demande et n'en ont rien à foutre dans la mesure ou on ne peut rien leur reprocher. Sans parler des situations ou on sait que l'utilisateur ne sera pas satisfait quoi que l'on fasse. C'est d'ailleurs utile d'avoir un chef de projet qui filtre les évolutions dans le cas d'un projet au forfait.

                  • [^] # Re: Ce n'est pas ce qu'il dit.

                    Posté par . Évalué à  3 .

                    Il ne faut pas oublier que certain se contente de faire ce que l'on demande et n'en ont rien à foutre dans la mesure ou on ne peut rien leur reprocher.

                    Alors c'est dehors. Tu gagnes beaucoup plus à avoir une équipe qui bosse en interagissant avec le client qu'à mettre un "chef de projet" qui est censé rattrapé les choses par magie. D'une manière générale dès que tu as des phrases du type "certains XXXX font toujours YYYYY" c'est que tu as un problème qu'il faut résoudre.

                    Sans parler des situations ou on sait que l'utilisateur ne sera pas satisfait quoi que l'on fasse.

                    A partir du moment où c'est le client qui rempli le backlog, que c'est lui qui l'ordonne et que l'équipe(s) fait son job en donnant un avis pertinent sur les choix et qu'elle livre ce sur quoi elle s'est engagée avec la qualité souhaitée si il est pas content c'est de sa faute. Il a choisi chaque brique en étant pleinement conscient de chaque choix.

                    C'est d'ailleurs utile d'avoir un chef de projet qui filtre les évolutions dans le cas d'un projet au forfait.

                    En même temps projet au forfait ça va direct dans le mur. Puisque non seulement les specs mais aussi les coûts sont fixés la seule variable d'ajustement possible est la qualité. Utiliser la qualité comme variable d'ajustement est toujours la pire chose à faire. Bref la tu combines les problèmes du modèle en cascade dont on parlait avec une relation contractuelle qui te fait encore perdre des variables d'ajustement.

                    • [^] # Re: Ce n'est pas ce qu'il dit.

                      Posté par . Évalué à  3 .

                      Il m'est arrivé qu'on me dise que j'étais payé pour faire ce que l'on me demandait. Le problème à la base, c'est que soit je n'avais pas compris ce qu'on me demandait, soit que l'on me demandait des conneries. Dans les 2 cas, il y avait certainement un problème à régler ou le résultat ne risquait pas d'être bon.

                      Il m'est également arrivé de voir des gens (moi compris) rester chez un client alors qu'ils demandaient à partir depuis longtemps et que le client le savait pertinemment. Le plus drôle c'est qu'on s'étonne quand même d'un manque de motivation ou d'une démission.

                      Je suis chez un client ou l'on m'a fait passé un test d'ASP avant de me prendre. J'ai raté lamentablement le test, mais j'ai été pris pour d'autres compétences (gros système IBM). Résultat, je me retrouve spécialiste ASP chargé de tout les trucs un peu compliqués parce que je sais aligner 2 tag HTML. Je travaille avec des gens qui après un arrêt de traitement (response.end) croient que le programme va continuer la ou il s'est arrêté après la saisie de l'utilisateur. En plus, ils ne savent même pas que les fonctions, ca existe.

                      Je ne suis pas sur que les problèmes viennent uniquement des chefs de projets. Bons ou mauvais. Les problèmes viennent souvent d'un déséquilibre en informaticiens et utilisateurs. Que ce soit les boites ou les informaticiens font la loi ou les boites ou les utilisateurs font la loi.

      • [^] # Re: Ce n'est pas ce qu'il dit.

        Posté par . Évalué à  4 .

        Moui, à condition de considérer que des paramètres comme la culture des gens, leurs habitudes, leurs références, leur façon de parler, sont des paramètres techniques.

        Je rangerais plutôt ça dans la catégorie "compétences humaines", en vrac avec le management, les DRH, les commerciaux, et tout ces gens bizarres.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # manque un lien ?

    Posté par (page perso) . Évalué à  4 .

    Je pense qu'il manque un lien dans ton journal

    GnuTLS, copyright assignment, and GNU project governance

    les pixels au peuple !

    • [^] # Re: manque un lien ?

      Posté par (page perso) . Évalué à  9 .

      C'était un choix, je ne suis pas favorable à la distribution large des "liens d'abonnés" LWN (même quand ils ont déjà été postés sur une liste de diffusion publique, ce n'est pas une raison).

      • [^] # Re: manque un lien ?

        Posté par (page perso) . Évalué à  3 .

        C'était un choix, je ne suis pas favorable à la distribution large des "liens d'abonnés" LWN

        Mea culpa. Je n'avais pas fait gaffe à ça.
        Ceci dit c'est de loin le contenu le plus trollesque, ce serait dommage de s'en priver.

        les pixels au peuple !

  • # Prochain mainteneur pour sed ?

    Posté par (page perso) . Évalué à  2 .

    Paolo Bonzini était le seul mainteneur de sed ? Il y a quelqu'un pour le remplacer ? Je ne vois aucune information à ce sujet.

    Beaucoup d'outils comme sed conviennent maintenant à la plupart des besoins des utilisateurs. Il y a de moins en moins de raisons de vouloir contribuer. Ce n'était à mon avis pas le cas dans les années 90. Je peux me tromper, mais je pense qu'en faisant des statistiques, on pourrait voir que ces dernières années il y a moins de contributions que dans les années 90. Pourtant, pour la pérennité à long terme de ces logiciels, il faut de nouveaux développeurs, qui doivent être suffisamment calé dans le domaine.

    Y aura-t-il toujours des développeurs suffisamment compétents pour maintenir les trucs comme sed ?

    Le risque est qu'un jour, plus personne ne comprenne pourquoi certaines parties du code ont été écrite d'une telle manière, puisque plus personne n'y a touché depuis des années, et que la personne ayant écrit le code n'a pas laissé suffisamment de documentation ou de commentaires, et que la personne n'est plus disponible.

    Je pense qu'à long terme, c'est un risque qu'il ne faut pas négliger, et donc, raison de plus pour bien documenter son code ;)

    « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

    • [^] # Re: Prochain mainteneur pour sed ?

      Posté par (page perso) . Évalué à  3 .

      En fait je me pose une question : en quoi sed a besoin d'avoir un mainteneur ? C'est un logiciel qui est normalement très documenté, qui par différentes normes et compatibilités est limité dans son évolution et je suppose qu'il a très peu de bogues (voir aucun ?).

      Je pose cette question sérieusement car j'ai du mal à voir l'intérêt de faire évoluer un programme de ce type étant données les circonstances.

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par (page perso) . Évalué à  3 .

        Il y aura toujours un peu de maintenance à faire, pour que ça fonctionne toujours bien avec les dernières versions des dépendances, et pour porter si besoin le code sur d'autres plateformes. Bien que pour sed il ne doit pas y avoir beaucoup de dépendances, et elles sont à mon avis très stable (pas de cassage de l'API à tout bout de champ).

        Et si un jour un chercheur publie un article avec un tout nouveau algorithme ayant une complexité calculatoire moindre, c'est toujours intéressant de l'implémenter, pour ne pas rester à la traine par rapport aux autres implémentations.

        « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par . Évalué à  5 .

        En fait je me pose une question : en quoi sed a besoin d'avoir un mainteneur ?

        http://git.savannah.gnu.org/cgit/sed.git/log/

        • [^] # Re: Prochain mainteneur pour sed ?

          Posté par (page perso) . Évalué à  4 .

          Wow, je ne savais pas qu'il y avait encore du code avec la vielle syntaxe de paramètre sur une ligne séparée…

          http://git.savannah.gnu.org/cgit/sed.git/tree/sed/sed.c

          static void
          contact(errmsg)
            int errmsg;
          {
          /// [...]
          }
          
          
          • [^] # Re: Prochain mainteneur pour sed ?

            Posté par (page perso) . Évalué à  1 .

            C'est ce qu'on appelle le C K&R. Le prototype d'une fonction tel qu'on le connait aujourd'hui a été amené par le C++ (et introduit par ANSI) et ce style de déclaration n'est d'ailleurs pas possible en C++. C'était une histoire de compatibilité à l'époque, c'est aujourd'hui une histoire de style. Ici d'ailleurs, on a un sacré mélange entre K&R et le style GNU. Peut être qu'ils veulent que le code soit aussi compilable avec un compilateur C des années 70 (ce qui ne m'étonnerait pas).

            • [^] # Re: Prochain mainteneur pour sed ?

              Posté par (page perso) . Évalué à  2 .

              Peut être qu'ils veulent que le code soit aussi compilable avec un compilateur C des années 70 (ce qui ne m'étonnerait pas).

              En voyant ce récent commit, justement on dirait que ce n'est plus une priorité.

              « Un animal d'une atterrante stupidité : il est persuadé que si vous ne le voyez pas, il ne vous voit pas non plus » (H2G2)

            • [^] # Re: Prochain mainteneur pour sed ?

              Posté par (page perso) . Évalué à  3 .

              Peut être qu'ils veulent que le code soit aussi compilable avec un compilateur C des années 70 (ce qui ne m'étonnerait pas).

              Seulement pour les programmes qui sont déjà compilables avec un compilateur pré-C89, dont les mainteneurs sont invités à ne pas changer ça. Sinon, c’est laissé à la discrétion des développeurs.

              Extrait des GNU Coding Standards :

              1989 Standard C is widespread enough now that it is ok to use its features in new programs. […] However, it is easy to support pre-standard compilers in most programs, so if you know how to do that, feel free. If a program you are maintaining has such support, you should try to keep it working.

    • [^] # Re: Prochain mainteneur pour sed ?

      Posté par . Évalué à  9 .

      Bah, Lennart va passer par là et va te remplacer ça par un truc qui nécessite 3 daemons, 2 bus logiciels, et de réécrire toute la gestion des caractères sous Linux pour un truc qui va marcher moins bien ….

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par . Évalué à  10 .

        Oui mais ça permettra de faire du sed sur les caractères écrits dans une vidéo en Flash© postée sur Facebook©, grâce à ocr-http-social-networks-swf-daemon (une dépendance de Gnome, sous Ubuntu).

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par (page perso) . Évalué à  2 .

        Mais non! Tu ne peux pas dire ça comme ça!
        Il faut que les démons soient chargés, parce que sinon la fonction pour faire du traitement de chaines de caractères par des illettrés au login de Gnome ne marche pas… à moins que tu haïsses les illettrés?!

        Et ça passe par dbus parce que dbus marche très bien pour toutes ces choses!

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par . Évalué à  4 .

        Trop compliqué
        Remplaçons le tout par Powershell ça ira plus vite.

      • [^] # Re: Prochain mainteneur pour sed ?

        Posté par . Évalué à  -6 .

        réécrire toute la gestion des caractères sous Linux pour un truc qui va marcher moins bien

        Déjà fait: UTF8

  • # sed

    Posté par (page perso) . Évalué à  1 .

    sed sed.orig s/mainteneur/nouveau_mainteneur/g > sed.new

    • [^] # Re: sed

      Posté par . Évalué à  10 .

      Plus simple :

      $ sed -i s/mainteneur/nouveau_mainteneur/g sed
      
      

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # sedépassé

    Posté par . Évalué à  1 .

    …C'est comme ça

    ---> []

Suivre le flux des commentaires

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