Time Nick Message 08:35 rubenwardy can't update the Android app on Google Play as we need a privacy policy 08:42 rubenwardy #12809 08:42 ShadowBot https://github.com/minetest/minetest/issues/12809 -- Privacy Policy 08:45 Zughy[m] Reminder to consider TurkeyMcMac as a potential core dev: there have been 12 new PRs in 3 days, you need someone to help you 08:46 Zughy[m] rubenwardy: I'd put it for 5.7, considering that is a blocker 08:46 rubenwardy needs to be done before that, as it's required to release 5.6.1 08:46 rubenwardy no need for a new release for it as Google Play wants a URL 09:08 rubenwardy I think that the update notification puts "NEver" too prominently. It should prioritise "not again for this release" and "remind me later" over "Never / disable" 09:15 appguru Suggestion: Prioritize small PRs over larger ones. This minimizes the time spent waiting for PRs to be merged (I'm eyeballing #11634 in particular). Tiny bugfixes should take priority over large features & refactors. 09:15 ShadowBot https://github.com/minetest/minetest/issues/11634 -- Custom error handler 09:40 Zughy[m] It won't fix the problem, you'll soon find yourself with a huge pile of large PRs at the bottom 09:41 Zughy[m] If this pace doesn't slow down and they don't want to find themselves drowning in PRs again, they need help 09:43 Zughy[m] Also, 13 are from Turkey https://github.com/minetest/minetest/pulls/TurkeyMcMac 10:22 rubenwardy I already prioritise smaller and bug fixes 10:30 appguru Zughy: It can't fix the problem of core devs being unable to keep up with PRs, but it can definitely fix the problem of total time spent waiting for PRs to be merged being highly suboptimal. 10:30 appguru Prioritizing smaller PRs minimizes the total time spent waiting for PRs to be merged. 11:36 Zughy[m] "one approval" label missing, and I don't have any rights in this repo https://github.com/minetest/irrlicht/pull/129 17:17 jwmhjwmh Are "dummy" mapblocks actually created under any circumstance? I can't find any place where they are. 17:17 MTDiscord uneducated guess, related to the dummy sql backend? 17:18 MTDiscord . s/sql/map 17:19 jwmhjwmh The dummy backend just keeps everything in memory. Dummy mapblocks are blocks whose data pointer is null. 18:21 MTDiscord Zughy[m]: I've added the label to irrlicht/129 18:47 celeron55 i talked with TurkeyMcMac about becoming a core dev and he's up for it 18:47 celeron55 any comments? (/msg is fine too) 18:48 celeron55 i think i'll add him to the core team tomorrow if nothing pops up 20:27 Krock no objections. It would however be nice if they could check in on IRC or one of its relays if that did yet not happen 20:28 jwmhjwmh I'm here. 20:28 Krock jwmhjwmh: aren't dummy mapblocks used on client-side for unloaded blocks? 20:29 Krock > Dummy blocks are used for caching not-found-on-disk blocks. 20:30 sfan5 maybe that feature broke during one of the rewrites if you didn't find anything 20:31 jwmhjwmh I tried removing dummy blocks entirely (calls to isDummy() etc.) and there were no errors. Many checks could be removed. 20:32 Krock now that you mention it, there's indeed no constructor calls for it 20:32 Krock dummy mapblocks make sense if you do not want to waste RAM by allocating a bunch of CONTENT_IGNORE nodes 20:34 jwmhjwmh I'm working on a patch to speed up mapblock access a bit. The array of nodes can be stored directly in an object rather than behind a pointer. Removing dummy blocks would simplify the code and reduce the checks required. 20:35 rubenwardy confused me when people use drastically different usernames on different platforms 20:35 rubenwardy -d+s 20:36 jwmhjwmh Sorry. I like to use "jwmhjwmh" because it sounds less ridiculous than "TurkeyMcMac". I chose "TurkeyMcMac" for my GitHub a long time ago and it's hard to change it now. 23:07 schwarzwald[m] I love your GitHub handle, TurkeyMcMac. I think it's a great name. xD 23:19 jwmhjwmh schwarzwald[m]: Thanks.