Merci pour la traduction, mais c’est pas très facile à lire avec une alternance quasi ligne par ligne. Ne serait-il pas plus lisible de rassembler les paragraphes ?
J’imagine que la dépêche est restée au moins six mois dans les tuyaux donc je ne fais aucun reproche et j’accepte la remarque qui dirait que je n’avais qu’à le faire :p.
Je trouve que c’est plus lisible ainsi, et j’ai aussi corrigé deux problèmes (itâs, peopleâs) et échappé quelques * et _ pour garder le style original et éviter l’interprétation de markdown et la confusion avec les emphases du traducteur (indiquant par exemple les mots anglais repris tels-quels), j’ai ajouté une emphase sur le mot non-traduit « tar-balls » dans la traduction. J’ai aussi francisé et modernisé un peu la typographie de la traduction (je n’ai pas touché au message original). J’ai seulement réordonné le texte, c’est la même traduction.
(Si un modérateur jugeait cette réorganisation utile et dans l’éventualité qu’elle remplace celle de la dépêche, tout ce qui suit pourrait être supprimé de mon commentaire et remplacé par un « snip » histoire de ne pas doubler inutilement le texte et conserver le sens de ce commentaire...)
Message de Linus et sa traduction
[ So this email got a lot longer than I initially thought it would get, but let's start out with the "regular Sunday release" part ]
Another week, another rc.
Nothing particularly odd stands out on the technical side in the kernel updates for last week - rc4 looks fairly average in size for this stage in the release cycle, and all the other statistics look pretty normal too.
We've got roughly two thirds driver fixes (gpu and networking look to be the bulk of it, but there's smaller changes all over in various driver subsystems), with the rest being the usual mix: core networking, perf tooling updates, arch updates, Documentation, some filesystem, vm and minor core kernel fixes.
So it's all fairly small and normal for this stage. As usual, I'm appending the shortlog at the bottom for people who want to get an overview of the details without actually having to go dig in the git tree.
The one change that stands out and merits mention is the code of conduct addition...
[Bon, ce courriel est un peu plus long que je l'aurais pensé au départ, mais commençons avec la partie "publication dominicale habituelle" ]
Une nouvelle semaine, une nouvelle RC.
Rien de particulier concernant les mises à jour de la partie technique pour la semaine dernière - la RC4 paraît plutôt normale en taille à cette étape du cycle de publication et toutes les autres statistiques semblent plutôt normales également.
Nous avons à peu près deux tiers de correctifs de pilotes (le gpu et le réseau semblent en être la majorité, mais il y a de petits changements un peu partout dans différents sous-systèmes des pilotes), le reste étant le mélange habituel : base du réseau, mise à jour d’architectures, documentation, un peu de systèmes de fichiers, les VM et des mises à jour mineures de la base du noyau.
Donc tout est plutôt petit et normal à cette étape. Comme d’habitude, je joins le journal abrégé [NDT. des modifications] en annexe pour les gens qui veulent un aperçu des détails sans avoir à fouiller dans l’arborescence git.
Le changement qui ressort et mérite d’être mentionné est l’addition du code de conduite.
[ And here comes the other, much longer, part... ]
Which brings me to the *NOT* normal part of the last week: the discussions (both in public mainly on the kernel summit discussion lists and then a lot in various private communications) about maintainership and the kernel community. Some of that discussion came about because of me screwing up my scheduling for the maintainer summit where these things are supposed to be discussed.
And don't get me wrong. It's not like that discussion itself is in any way new to this week - we've been discussing maintainership and community for years. We've had lots of discussions both in private and on mailing lists. We have regular talks at conferences - again, both the "public speaking" kind and the "private hallway track" kind.
No, what was new last week is really my reaction to it, and me being perhaps introspective (you be the judge).
[ Et ici commence l'autre partie, bien plus longue... ]
Ce qui m’amène à la partie *NON* normale de la semaine dernière : les discussions (en public, principalement sur la liste de discussion du kernel summit et beaucoup par divers moyens de communications privées) à propos de maintainership et de la communauté du noyau. Une partie de ces discussions a émergé par ma faute, car je me suis planté dans mon agenda pour le maintainer summit, où ces choses sont censées être discutées.
Ne vous méprenez pas. Ce n’est pas que cette discussion soit en elle-même nouvelle cette semaine – nous avons discuté de maintainership et de communauté depuis des années. Nous avons eu de nombreuses discussions tant en privé que sur les mailing list. Nous avons eu des discussions régulières à des conférences – à nouveau, tant lors de discussions publiques que lors de discussions de couloirs privées.
Non, ce qui est nouveau la semaine passée est vraiment ma réaction à cela et peut-être un peu d’introspection de ma part (je vous laisse juges).
There were two parts to that.
One was simply my own reaction to having screwed up my scheduling of the maintainership summit: yes, I was somewhat embarrassed about having screwed up my calendar, but honestly, I was mostly hopeful that I wouldn't have to go to the kernel summit that I have gone to every year for just about the last two decades.
Yes, we got it rescheduled, and no, my "maybe you can just do it without me there" got overruled. But that whole situation then started a whole different kind of discussion. And kind of incidentally to that one, the second part was that I realized that I had completely mis-read some of the people involved.
This is where the "look yourself in the mirror" moment comes in.
So here we are, me finally on the one hand realizing that it wasn't actually funny or a good sign that I was hoping to just skip the yearly kernel summit entirely, and on the other hand realizing that I really had been ignoring some fairly deep-seated feelings in the community.
Il y a eu deux volets.
L’un était ma propre réaction d’avoir bousillé mon planning du maintainership summit : oui, j’étais quelque peu embarrassé d’avoir gâché mon calendrier, mais honnêtement, j’espérais ne pas avoir à aller au kernel summit auquel je vais chaque année depuis près de vingt ans.
Oui, nous l’avons reprogrammé, et non, mon « peut-être que vous pouvez juste faire sans moi » a été rejeté. Mais cette situation a alors généré un tout autre genre de discussions. Et, incidemment, il s’avère que j’avais mal interprété les écrits de certaines des personnes impliquées. [NDT. Syntaxe anglaise pourrie, si quelqu’un fait mieux, je prends.]
C’est là que le moment « regarde-toi dans le miroir » arrive.
Et nous y voilà, moi, réalisant finalement, d’une part que ce n’était en fait pas drôle, ni un bon signe d’espérer juste sauter le kernel summit annuel et, d’autre part, que j’avais vraiment ignoré certains sentiments assez profonds dans la communauté.
It's one thing when you can ignore these issues. Usually it's just something I didn't want to deal with.
This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good.
This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.
The above is basically a long-winded way to get to the somewhat painful personal admission that hey, I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely.
I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately.
C’est une chose lorsque vous pouvez ignorer ces problèmes. Généralement, c’est juste quelque chose à laquelle je ne voulais pas avoir à me confronter.
C’est ma réalité, je ne suis pas quelqu’un d’empathique par nature et ce n’est probablement une surprise pour personne. Et certainement pas pour moi. Le fait que j’ai mal compris les gens et que je n’ai pas réalisé (pendant des années) combien j’avais mal jugé la situation et contribué à un environnement non professionnel n’est pas bon.
Cette semaine, les gens dans notre communauté m’ont confronté à ma vie, passée à ne pas comprendre les émotions. Mes attaques désinvoltes dans les courriels ont été à la fois non professionnelles et indues. En particulier les fois où elles furent personnelles. Dans ma quête de meilleurs rustines, c’était sensé pour moi. Je sais maintenant que ce n’était pas acceptable et je suis sincèrement désolé.
Ce qui précède est simplement un long chemin tortueux pour arriver à admettre personnellement de façon quelque peu douloureuse que hé, je dois changer mon comportement. Et je tiens à présenter mes excuses aux personnes que mon comportement a blessé et potentiellement complètement éloigné du développement du noyau.
Je vais prendre un congé et demander de l’aide pour comprendre les émotions des gens et comment répondre de façon adaptée.
Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been about the _technical_ issues, but about the inflection points where development flow and behavior changed.
These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us.
We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me.
To tie this all back to the actual 4.19-rc4 release (no, really, this _is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior.
En d’autres termes, lorsque je suis interrogé lors de conférences, je parle parfois du fait que les points irritants dans le développement du noyau ne sont généralement pas le fait de problèmes _techniques_, mais de points d’inflexion où le flot et les pratiques de développement évoluent.
Ces points irritants concernent la gestion du flot de rustines, souvent associées avec de gros changements d’outils – passant de publications « rustines et tar-balls » (et la discussion _vraiment_ difficile que « Linus ne délègue pas » il y a plus de 15 ans de cela) à l’utilisation de BitKeeper, puis à avoir à écrire git pour dépasser le point où ça ne marcherait plus pour nous.
Nous n’avons pas eu de point de douleur en près de dix ans. Mais cette semaine, je l’ai ressentie comme un point de douleur.
Pour rattacher tout cela à la publication du 4.19-rc4 (non, sérieux, c’est _vraiment_ lié), je pense en fait que la 4.19 se présente assez bien, la période « calme » du cycle de publication arrive et j’ai demandé à Greg s’il pouvait s’occuper de terminer la 4.19 pour moi, de sorte que je puisse faire une pause et essayer de corriger mon propre comportement.
This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades.
This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.
And yes, some of it might be "just" tooling. Maybe I can get an email filter in place so at when I send email with curse-words, they just won't go out. Because hey, I'm a big believer in tools, and at least _some_ problems going forward might be improved with simple automation.
I know when I really look "myself in the mirror" it will be clear it's not the only change that has to happen, but hey... You can send me suggestions in email.
I look forward to seeing you at the Maintainer Summit.
Linus
Ce n’est pas une espèce de pause « je suis épuisé, il faut que je parte ». Je ne ressens pas de répulsion à continuer à maintenir Linux. Au contraire. Je veux *vraiment* continuer à mener ce projet sur lequel je travaille depuis près de trente ans.
C’est plutôt comme la fois où je me suis retiré du développement du noyau quelque temps, parce qu’il fallait que j’écrive un petit outil appelé « git ». J’ai besoin de faire une pause pour trouver de l’aide pour me comporter différemment et corriger quelques problèmes dans mon outillage et mon processus de travail.
Et oui, une partie pourrait n’être « que » de l’outillage. Peut-être que je peux mettre en place un filtre de sorte que lorsque j’envoie un courriel avec des gros mots, il ne parte simplement pas. Parce que, hé, je crois fermement aux outils et au moins, _certains_ problèmes pourraient être améliorés avec une simple automatisation.
Je sais, quand « je me regarde vraiment dans le miroir », qu’il est clair que ce n’est pas la seule chose qui doit changer, mais hé... Vous pouvez m’envoyer des suggestions par mail.
J’ai hâte de vous revoir au Maintainer summit.
Linus
ce commentaire est sous licence cc by 4 et précédentes
# Merci pour la traduction
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Il y a six mois Linus décidait de changer, a‐t‐il réussi ?. Évalué à 10. Dernière modification le 25 mars 2019 à 19:02.
Merci pour la traduction, mais c’est pas très facile à lire avec une alternance quasi ligne par ligne. Ne serait-il pas plus lisible de rassembler les paragraphes ?
J’imagine que la dépêche est restée au moins six mois dans les tuyaux donc je ne fais aucun reproche et j’accepte la remarque qui dirait que je n’avais qu’à le faire :p.
Je trouve que c’est plus lisible ainsi, et j’ai aussi corrigé deux problèmes (
itâs,peopleâs) et échappé quelques * et _ pour garder le style original et éviter l’interprétation de markdown et la confusion avec les emphases du traducteur (indiquant par exemple les mots anglais repris tels-quels), j’ai ajouté une emphase sur le mot non-traduit « tar-balls » dans la traduction. J’ai aussi francisé et modernisé un peu la typographie de la traduction (je n’ai pas touché au message original). J’ai seulement réordonné le texte, c’est la même traduction.(Si un modérateur jugeait cette réorganisation utile et dans l’éventualité qu’elle remplace celle de la dépêche, tout ce qui suit pourrait être supprimé de mon commentaire et remplacé par un «
snip» histoire de ne pas doubler inutilement le texte et conserver le sens de ce commentaire...)Message de Linus et sa traduction
[Bon, ce courriel est un peu plus long que je l'aurais pensé au départ, mais commençons avec la partie "publication dominicale habituelle" ]
Une nouvelle semaine, une nouvelle RC.
Rien de particulier concernant les mises à jour de la partie technique pour la semaine dernière - la RC4 paraît plutôt normale en taille à cette étape du cycle de publication et toutes les autres statistiques semblent plutôt normales également.
Nous avons à peu près deux tiers de correctifs de pilotes (le gpu et le réseau semblent en être la majorité, mais il y a de petits changements un peu partout dans différents sous-systèmes des pilotes), le reste étant le mélange habituel : base du réseau, mise à jour d’architectures, documentation, un peu de systèmes de fichiers, les VM et des mises à jour mineures de la base du noyau.
Donc tout est plutôt petit et normal à cette étape. Comme d’habitude, je joins le journal abrégé [NDT. des modifications] en annexe pour les gens qui veulent un aperçu des détails sans avoir à fouiller dans l’arborescence git.
Le changement qui ressort et mérite d’être mentionné est l’addition du code de conduite.
[ Et ici commence l'autre partie, bien plus longue... ]
Ce qui m’amène à la partie *NON* normale de la semaine dernière : les discussions (en public, principalement sur la liste de discussion du kernel summit et beaucoup par divers moyens de communications privées) à propos de maintainership et de la communauté du noyau. Une partie de ces discussions a émergé par ma faute, car je me suis planté dans mon agenda pour le maintainer summit, où ces choses sont censées être discutées.
Ne vous méprenez pas. Ce n’est pas que cette discussion soit en elle-même nouvelle cette semaine – nous avons discuté de maintainership et de communauté depuis des années. Nous avons eu de nombreuses discussions tant en privé que sur les mailing list. Nous avons eu des discussions régulières à des conférences – à nouveau, tant lors de discussions publiques que lors de discussions de couloirs privées.
Non, ce qui est nouveau la semaine passée est vraiment ma réaction à cela et peut-être un peu d’introspection de ma part (je vous laisse juges).
Il y a eu deux volets.
L’un était ma propre réaction d’avoir bousillé mon planning du maintainership summit : oui, j’étais quelque peu embarrassé d’avoir gâché mon calendrier, mais honnêtement, j’espérais ne pas avoir à aller au kernel summit auquel je vais chaque année depuis près de vingt ans.
Oui, nous l’avons reprogrammé, et non, mon « peut-être que vous pouvez juste faire sans moi » a été rejeté. Mais cette situation a alors généré un tout autre genre de discussions. Et, incidemment, il s’avère que j’avais mal interprété les écrits de certaines des personnes impliquées. [NDT. Syntaxe anglaise pourrie, si quelqu’un fait mieux, je prends.]
C’est là que le moment « regarde-toi dans le miroir » arrive.
Et nous y voilà, moi, réalisant finalement, d’une part que ce n’était en fait pas drôle, ni un bon signe d’espérer juste sauter le kernel summit annuel et, d’autre part, que j’avais vraiment ignoré certains sentiments assez profonds dans la communauté.
C’est une chose lorsque vous pouvez ignorer ces problèmes. Généralement, c’est juste quelque chose à laquelle je ne voulais pas avoir à me confronter.
C’est ma réalité, je ne suis pas quelqu’un d’empathique par nature et ce n’est probablement une surprise pour personne. Et certainement pas pour moi. Le fait que j’ai mal compris les gens et que je n’ai pas réalisé (pendant des années) combien j’avais mal jugé la situation et contribué à un environnement non professionnel n’est pas bon.
Cette semaine, les gens dans notre communauté m’ont confronté à ma vie, passée à ne pas comprendre les émotions. Mes attaques désinvoltes dans les courriels ont été à la fois non professionnelles et indues. En particulier les fois où elles furent personnelles. Dans ma quête de meilleurs rustines, c’était sensé pour moi. Je sais maintenant que ce n’était pas acceptable et je suis sincèrement désolé.
Ce qui précède est simplement un long chemin tortueux pour arriver à admettre personnellement de façon quelque peu douloureuse que hé, je dois changer mon comportement. Et je tiens à présenter mes excuses aux personnes que mon comportement a blessé et potentiellement complètement éloigné du développement du noyau.
Je vais prendre un congé et demander de l’aide pour comprendre les émotions des gens et comment répondre de façon adaptée.
En d’autres termes, lorsque je suis interrogé lors de conférences, je parle parfois du fait que les points irritants dans le développement du noyau ne sont généralement pas le fait de problèmes _techniques_, mais de points d’inflexion où le flot et les pratiques de développement évoluent.
Ces points irritants concernent la gestion du flot de rustines, souvent associées avec de gros changements d’outils – passant de publications « rustines et tar-balls » (et la discussion _vraiment_ difficile que « Linus ne délègue pas » il y a plus de 15 ans de cela) à l’utilisation de BitKeeper, puis à avoir à écrire git pour dépasser le point où ça ne marcherait plus pour nous.
Nous n’avons pas eu de point de douleur en près de dix ans. Mais cette semaine, je l’ai ressentie comme un point de douleur.
Pour rattacher tout cela à la publication du 4.19-rc4 (non, sérieux, c’est _vraiment_ lié), je pense en fait que la 4.19 se présente assez bien, la période « calme » du cycle de publication arrive et j’ai demandé à Greg s’il pouvait s’occuper de terminer la 4.19 pour moi, de sorte que je puisse faire une pause et essayer de corriger mon propre comportement.
Ce n’est pas une espèce de pause « je suis épuisé, il faut que je parte ». Je ne ressens pas de répulsion à continuer à maintenir Linux. Au contraire. Je veux *vraiment* continuer à mener ce projet sur lequel je travaille depuis près de trente ans.
C’est plutôt comme la fois où je me suis retiré du développement du noyau quelque temps, parce qu’il fallait que j’écrive un petit outil appelé « git ». J’ai besoin de faire une pause pour trouver de l’aide pour me comporter différemment et corriger quelques problèmes dans mon outillage et mon processus de travail.
Et oui, une partie pourrait n’être « que » de l’outillage. Peut-être que je peux mettre en place un filtre de sorte que lorsque j’envoie un courriel avec des gros mots, il ne parte simplement pas. Parce que, hé, je crois fermement aux outils et au moins, _certains_ problèmes pourraient être améliorés avec une simple automatisation.
Je sais, quand « je me regarde vraiment dans le miroir », qu’il est clair que ce n’est pas la seule chose qui doit changer, mais hé... Vous pouvez m’envoyer des suggestions par mail.
J’ai hâte de vous revoir au Maintainer summit.
Linus
ce commentaire est sous licence cc by 4 et précédentes