IRC #olimex 2021-10-21

[13:22:19] <mps> jonas: hi. I tried yesterday to convince sunxi devs on #linux-sunxi to accept patches for fixed mmc ordering in kernel but looks like they are against
[13:40:46] <jonas> URI or it doesn't exist ;-)
[13:41:05] <jonas> oh, it was on chat :-/
[13:41:22] <mps> yes, if they have irc log
[13:41:50] <jonas> the proper place to propose patches is a mailinglist
[13:42:24] <mps> heh, and enjoy endless discussion ;)
[13:58:48] <jonas> as opposed to noreal discussion, only casual chatter? Yes!
[14:07:38] <mps> yes but. mripard is maintainer of arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts and s/he is strongly against
[14:09:10] <mps> I don't want to waste time, I can keep patches for my builds.
[14:14:04] <jonas> good luck with that
[14:15:52] <mps> thanks
[14:16:21] <mps> jonas: if you need them I can post both, for teres and a64 olinuxino
[14:23:17] <jonas> I do not need them for some Sisyphos move of endlessly maintaining a slight fork of linux - I need them to end in mainline linux
[14:24:34] <jonas> ...or at least that is my stand with my current knowledge - since only chatter exist, no proper public discussion, I don't know if I maybe agree with Rippard
[14:25:44] <jonas> ...or if perhaps I would notice a misunderstanding between you and Rippard (who is also not a native english speaker, as I recall) and I might help by contributing to the discussion
[14:30:34] <mps> thank you for goodwill, but I don't want to talk with mripard again about this, as I told there that I don't want to impose my POV on this
[14:34:41] <mps> and btw, as linux distro developer I'm accustomed to making patches for different things
[14:45:21] <jonas> I don't doubt your skills
[14:47:31] <mps> I think your skills are higher than mine
[14:48:54] <jonas> different
[14:49:15] <jonas> ...and also, it is not a competition :-)
[14:50:22] <mps> right
[14:51:19] <mps> I see all of us as collaborators or associates
[14:52:05] <jonas> I mean, even if I had your kernel hacking skills (which I don't) then what I would "win" by being "better than you" would only be the added burden of doing the work that I am encouraging you to (not only do for yourself but) do for the common good
[14:59:45] <mps> oh no, I don't have high kernel skill, just fixing some simple bugs and changing some behaviior I need for some use cases
[15:04:23] <jonas> who said anything about "high kernel skills"?
[15:04:42] <mps> :)
[18:53:02] <adjtm> mps, not sending your patches to the mailing list means that they will probably be lost, and even if people are able to find them nobody will remember why they were rejected and what you or anyone else need to improve to get them accepted
[18:53:34] <adjtm> in my experience with android patches not accepted upstream is a big pain in the ass
[19:21:20] <kveremitz> ugh android.
[19:39:49] <mps> adjtm: hmm, this is something for me to rethink my stance on patches
[19:43:21] <adjtm> kveremitz, the main problem is not android itself, but the ugly patched vendor kernels
[19:44:53] <adjtm> mps, I have made myself before the mistake of chatting on technical proposals and being pissed off by the response of the maintainers (debian-security in my case)
[19:45:50] <adjtm> I should have made the proposals properly on the mailing list, with something public to dialog about
[19:45:59] <mps> that depends on people with whom we chat, ime
[19:46:16] <adjtm> in the end, years later, some of my proposals have happened in debian
[19:46:44] <mps> that happens to from time to time
[19:46:58] <adjtm> in my case, I got replies of the kind "that's not a security problem, and in many cases a feature"
[19:47:08] <adjtm> I was quite angry about that
[19:47:42] <adjtm> if I had proposed it in the mailing list it would have probably happened before
[19:47:43] <mps> long ago I learned to be calm on all communication channels
[19:47:50] <adjtm> :)
[19:48:22] <mps> it is not worth to show others even if I lost nerves sometimes ;)
[20:00:10] <kveremitz> adjtm: the problem is almost always the 'ecosystem' not the components within it :D
[20:00:53] <kveremitz> or quite often at least :D
[20:01:09] <adjtm> almost always, if there is a vendor kernel then it is not
[20:01:10] <adjtm> :)
[20:02:13] <kveremitz> well.. I've used quite a few hit-and-miss vendor kernels over the years
[20:02:20] <kveremitz> mainline seems to be most consistent :D
[20:02:30] <kveremitz> (taking aside the constant stream of patches)
[20:02:49] <kveremitz> damned if...