01:45 <moto-timo> rpcme: are you subscribed to the list?

01:45 <moto-timo> rpcme: and https://patchwork.yoctoproject.org is the live instance

01:51 <moto-timo> rpcme: to subscribe https://lists.openembedded.org/g/openembedded-core/join

09:12 <RP> rpcme: as tim mentions, you should send them to the mailing list, probably openembedded-core

11:23 <rpcme> @moto

11:24 <rpcme> moto-timo RP The wiki doesn't say to subscribe to the list... or if it does it is buried... maybe a nice crisp "Requirements" section at the top will help. I joined and will see if that helps.

11:30 <rpcme> Yes that did it - thank you Tim. Well it's a start to trying to get some kind of contribution cadence going. Let's see how it goes:)

14:55 <rpcme> Ok after revisiting the instructions I do see I walked right by "task two".  I have edited that section for readability and have noted the behavior when the contributor is not subscribed. https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Subscribe_to_the_mailing_list

15:28 <JaMa> abelloni: OK, I don't see any feedback on https://patchwork.yoctoproject.org/project/oe-core/patch/20230209142717.13053-1-sdoshi@mvista.com/ for master (the 's/Upgrade OpenSSL/openssl: Upgrade/g' in commit summary was requested only by Steve on the review for langdale

15:29 <JaMa> I'll send https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=535246bc07aa4f21eae5c513af652e4cac39c092 as PATCHv3 on Monday if Siddharth doesn't reply sooner

15:30 <JaMa> but imho such commit message nitpick shouldn't block important security fix for 10+ days

18:58 <kanavin_> they should just rewrite the whole thing in rust or something

19:14 <JaMa> openssl?

19:25 <kanavin_> yeah

19:38 <kanavin_> I have a openssl update patch from AUH in my set, I suppose one or the other will land in master soon

21:05 <RP> JaMa: it shouldn't block it, no but nobody has sent a properly formatted patch until now :/

21:15 <JaMa> RP: I like consistency and nice commit messages, but in cases like this I would personally rather adjust the commit summary than wait for another revision to be sent for all 3 branches (especially for security fix), but I agree that original author should have sent it sooner (but the feedback was only on the langdale patch, so he might not notice or didn't realize that it blocks picking it to master as well)

21:21 <abelloni> so maybe they should avoid sending 3 patches

21:24 <JaMa> and how should they indicate that it's needed for langdale and kirkstone as well? just all 3 tags in subject? in this case the same version does apply to all 3 branches, but that's not always the case and might need 3 slightly different patches

21:25 <JaMa> but it's true that e.g. gmail groups the e-mails strangely, e.g. I see all PR requests from Steve as single thread even when they are for different branches

21:28 <JaMa> e.g. https://lists.openembedded.org/g/bitbake-devel/message/14454 and https://lists.openembedded.org/g/bitbake-devel/message/14455 are shown in the same thread even when they do have different subjects and different Message-Id and I don't see any In-reply-to as well

21:28 <abelloni> they could simply wait for the patch to be in master and then ask for the backport

21:28 <abelloni> which is the process anyway

21:29 <abelloni> pushing more work on the maintainers is never going to scale

22:16 <JaMa> kanavin_: I don't really care which version of openssl upgrade gets merged (the older one had more info in commit message about CVE-2023-0286, but yours was picked by abelloni)