From: Borislav Petkov <email@example.com> To: Nick Desaulniers <firstname.lastname@example.org> Cc: "Martin Liška" <email@example.com>, "Roman Kiryanov" <firstname.lastname@example.org>, "Rafael J. Wysocki" <email@example.com>, "Pavel Machek" <firstname.lastname@example.org>, "Thomas Gleixner" <email@example.com>, "Ingo Molnar" <firstname.lastname@example.org>, "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <email@example.com>, firstname.lastname@example.org, "Greg KH" <email@example.com>, "Alistair Delva" <firstname.lastname@example.org>, "Haitao Shan" <email@example.com>, lkml <firstname.lastname@example.org>, "Sami Tolvanen" <email@example.com>, clang-built-linux <firstname.lastname@example.org> Subject: Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang) Date: Wed, 16 Sep 2020 11:23:02 +0200 [thread overview] Message-ID: <20200916092302.GC2643@zn.tnic> (raw) In-Reply-To: <CAKwvOdmmXEu40m9bVL9zY5XyBRs2f15cs3FZQLCCh4u3i07pDA@mail.gmail.com> On Tue, Sep 15, 2020 at 02:49:40PM -0700, Nick Desaulniers wrote: > 1. they don't pay me enough for that. They probably should - you're doing it anyway and it's not like they have a shortage of cash. :-P > 2. even if they did, I wouldn't want that responsibility Too late, my friend. :-) > 3. I'm probably least qualified for that. Google has many strong > upstream contributors with much longer contribution history than > myself. Maybe toolchain specific stuff though... Sure, toolchain only, if you prefer. And others can take care of other areas. And yes, those people should have some time allocated only to upstream development. I think that's only fair... > 4. you generally don't want people like that in any organization. > More gatekeepers winds up being a synchronization/contention point. > Remember, the goal is to train others to be self sufficient, so you > can drink margaritas on the roof. That suggestion goes against the > ultimate goal. Sure, but there's the community and we want to support that. Business interest pays the bills but without the community to thrive around it, it is just another crap software. > 5. You'd think a multi-billion-dollar per quarter company could hire a > few more people to help; instead stock buybacks are more attractive I > guess? Maybe better ROI? I suspect one too many managers > internalized the Mythical Man Month's point about "adding more people > to a late software project just makes it later" to mean "starve your > projects for resources" and run a ghost-ship (ie. big boat, with > little to no deck hands to ensure the boat doesn't "Costa Concordia" > (noun-as-a-verb...oh well)). LOL. And true. My experience with managers is that they have no clue about how the open source community works. It is always the egotistic and omnipresent take take take and little or no give. > To be fair, hiring has been impacted by COVID; my point is more so > being stretched incredibly thin. There's been what, 3 Clang related > kernel bugs you and I have been CC'ed on today. Hard to fix compiler > bugs AND triage from the fire hose. I should probably just put down > LKML for today and start fixing the [haunted][damned] compiler. Oh, welcome to drinking from the firehose. This never stops. Ever! So yeah, even if you can hire more maintainers, there's always bottlenecks. > That's a rule for stable, yes. But also because we have folks that > don't seem to understand (moreso maybe haven't considered) that > "forking is not free" when upstream moves faster than you and you'd > also like to rebase someday; as such acquiring technical debt at a > rate that's impossible to pay off. I guess you need an upstreaming team which takes over technology produced by other projects - as those projects cannot slow down to adapt to the upstream pace - so they give the code to the upstreaming team after the project is done and they add it to the mainline kernel eventually. I think that would make a lot of sense for *everybody* involved. > I guess you're paying for beers then. "Android Common Kernels" run > mainline. (They're a bit esoteric in terms of "production" but > cuttlefish virtual devices are running Android on mainline). Only half of the beers - this "production" is a stretch - I mean infrastructure machines, not some funky toys. And *virtual* at that. :-) > Martin has patches for that, he has CC'ed me when sending them > upstream for review. Review was stalled, so I provided some feedback. > I'll review a GCC patch (once it's updated with my previous feedback) > if I have to; I'm not against it. w/e so long as we have a timeline > for a kernel fix. That's good. I guess it'll get there eventually. We'll still hold on to that fix for years, for those gccs which don't have the function attribute. Which is yet another reason for my aversion against compiler workarounds. > I CC'ed Martin on the LLVM bug, since this is a case I'm looking for > his input on, or at least for him to be aware of the test case. Cool. > I look forward to it. Ditto. :-) -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-09-16 9:23 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-15 17:26 rkir 2020-09-15 17:46 ` Borislav Petkov 2020-09-15 17:57 ` Roman Kiryanov 2020-09-15 18:27 ` Borislav Petkov 2020-09-15 18:36 ` Roman Kiryanov 2020-09-15 18:52 ` Borislav Petkov 2020-09-15 18:55 ` Roman Kiryanov 2020-09-18 22:25 ` Pavel Machek 2020-09-21 23:28 ` Roman Kiryanov 2020-10-04 9:59 ` Pavel Machek 2020-09-15 18:00 ` Nick Desaulniers 2020-09-15 18:25 ` Borislav Petkov 2020-09-15 19:51 ` Nick Desaulniers 2020-09-15 20:20 ` Borislav Petkov 2020-09-15 21:49 ` Nick Desaulniers 2020-09-16 9:23 ` Borislav Petkov [this message] 2020-09-19 16:48 ` Pavel Machek 2020-09-16 8:17 ` peterz 2020-09-15 20:44 ` Arvind Sankar 2020-09-15 22:17 ` Pavel Machek 2020-09-15 22:21 ` Nick Desaulniers 2020-09-18 22:20 ` Pavel Machek 2020-09-15 23:13 ` Roman Kiryanov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200916092302.GC2643@zn.tnic \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).