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 fapro . Évalué à 10.
C'est faux. Il dit que Stallman était, et est probablement toujours, un programmeur brillant, malgré son âge :
Par contre, il estime qu'il est nul comme leader de projet (sans doute parce qu'il n'est pas assez "sociable") :
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Philip Marlowe . É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 Frank-N-Furter . Évalué à 6.
C'est un coup de la cabal (qui n'existe pas) anti-motards.
Depending on the time of day, the French go either way.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par ploum (site web personnel, Mastodon) . Évalué à -1.
La gestion de projet, c'est aussi une compétence technique hein.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par cedric . É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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Renault (site web personnel) . É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).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Renault (site web personnel) . Évalué à 2. Dernière modification le 23 décembre 2012 à 23:50.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 24 décembre 2012 à 01:05.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Renault (site web personnel) . Évalué à 6.
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 totof2000 . Évalué à 4. Dernière modification le 24 décembre 2012 à 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 barmic . Évalué à 8.
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 devrais surtout changer de boite. Il y en a où le projet est géré par 3 responsables :
et un truc bien c'est que le chef de projet n'est pas ton chef !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par barmic . Évalué à 1.
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.
Non c'est juste des compétences différentes c'est donc reconnu comme tel (mais ça dépend de la taille des projets).
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Batchyx . Évalué à 1.
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 Didrik Pining . Évalué à 3.
Au contraire ;)
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par Prae . É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 Renault (site web personnel) . É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 Sufflope (site web personnel) . Évalué à 9.
C'est surtout que pour une SSII, si tu t'épanouis comme bon technicien, tu vas :
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 ploum (site web personnel, Mastodon) . É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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par claudex . É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.
« 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: Ce n'est pas ce qu'il dit.
Posté par 2PetitsVerres . É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 Prae . É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 2PetitsVerres . Évalué à 1.
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 Prae . É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 2PetitsVerres . Évalué à 2.
Ou alors c'est toi qui n'a pas suivi le fil depuis le début.
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 Prae . É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 mazarini . É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 ckyl . Évalué à 5.
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 mazarini . É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 ckyl . Évalué à 3.
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.
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.
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 mazarini . É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 Grunt . É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 Patrick Lamaizière (site web personnel) . É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 MrLapinot (site web personnel) . É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 Patrick Lamaizière (site web personnel) . Évalué à 3.
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 swilmet . É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 ;)
[^] # Re: Prochain mainteneur pour sed ?
Posté par Renault (site web personnel) . É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 swilmet . É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.
[^] # Re: Prochain mainteneur pour sed ?
Posté par ckyl . Évalué à 5.
http://git.savannah.gnu.org/cgit/sed.git/log/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Prochain mainteneur pour sed ?
Posté par Dinosaure (site web personnel) . É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 swilmet . Évalué à 2.
En voyant ce récent commit, justement on dirait que ce n'est plus une priorité.
[^] # Re: Prochain mainteneur pour sed ?
Posté par gouttegd (site web personnel) . Évalué à 3.
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 :
[^] # Re: Prochain mainteneur pour sed ?
Posté par Antoine . Évalué à 5.
Ça existe encore pour de vrai ?
[^] # Re: Prochain mainteneur pour sed ?
Posté par totof2000 . É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 Grunt . É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 Maclag . É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 MTux . Évalué à 4.
Trop compliqué
Remplaçons le tout par Powershell ça ira plus vite.
[^] # Re: Prochain mainteneur pour sed ?
Posté par Didrik Pining . Évalué à -6.
Déjà fait: UTF8
[^] # Re: Prochain mainteneur pour sed ?
Posté par Batchyx . Évalué à 4.
Tu confond avec le support des langues non-occidentales.
# sed
Posté par mac_is_mac (site web personnel) . Évalué à 1.
sed sed.orig s/mainteneur/nouveau_mainteneur/g > sed.new
[^] # Re: sed
Posté par zebra3 . Évalué à 10.
Plus simple :
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 maboiteaspam . Évalué à 1.
…C'est comme ça
---> []
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.