Time Nick Message 03:10 nekobro someone tell SFENCE to get a bouncer :D 03:11 MTDiscord its called discord 04:27 MTDiscord right; he's disconnecting/connecting a lot 07:20 MTDiscord Zughy, the ambient light is already fully ready, only a bit more testing needs (it was already tested thoroughly by me and also Herowl). It just needs a confirmation of it works from still a few people 07:23 MTDiscord It would be very frustrated if it was postponed other a few months for just nothing. Also, I have been tedious to rebase it many times (totally I rebased it as minimum 10 times since February) 08:05 [MatrxMT] Unfortunately it's a big risk that might introduce bugs and regressions we haven't noticed, forcing us to rush fixes before the release. I understand the rebase frustration, however, if the quality you're describing is there, I'm pretty sure that it'd be merged right away once 5.10 is released 08:06 [MatrxMT] We're renouncing to SDL once again as well, if that might be of any consolation.. 09:06 sfan5 btw there's no need to constantly rebase or merge (except if you want it for our own continued development) 09:06 sfan5 theoretically once before merge is enough 09:08 sfan5 @zughy re #15078: it's failing because the code is broken. what's left to do is adressing my comment. 09:08 ShadowBot https://github.com/minetest/minetest/issues/15078 -- [no-sq] Return SRP-style hash from `minetest.get_password_hash` by red-001 09:08 sfan5 I am asking for the changes to be simplified back to what they were before. incidentially this would also resolve the errors 09:20 sfan5 "our own continued development" -> your own of course 09:45 sfan5 merging #14659, #15040 in 15m 09:45 ShadowBot https://github.com/minetest/minetest/issues/14659 -- [no sq] Generic IPC mechanism between Lua envs by sfan5 09:45 ShadowBot https://github.com/minetest/minetest/issues/15040 -- Separate anticheat settings [#2] by zmv7 10:10 MTDiscord Zughy, why do you state my PR would introduce bugs and regressions now taking into account that fact the PR passed through the pretty deep testing multiple times by various people in the past? Did you compile and try out it? 10:14 MTDiscord Just I don't see any point in leaving it for still a few months during the next release cycle if it is in the fully ready state 10:14 sfan5 all PRs have certain risks of introducting regressions depending on the areas they touch 10:14 MTDiscord And moreover I did fix the critical bug with the hardware-colored nodes, this was the main problem 10:19 MTDiscord sfan5, that's yes, but I don't understand on which basis Zughy decided this has a high risk of bugs and that's the reason of which the PR must be postponed for 5.11 10:23 MTDiscord And that's why I asked him to clarify what he means 10:26 MTDiscord The whole engine is at high risk of bugs there's raw pointers all over the place 10:26 MTDiscord What bug have you fixed? 10:29 MTDiscord I fixed the bug with the incorrect mixing the hardware colors with the light ones in the shaders and final_color_blend(). See #15176 10:29 ShadowBot https://github.com/minetest/minetest/issues/15176 -- Decouple Ambient Occlusion from Shadows 10:31 MTDiscord What is the pr number? 10:35 MTDiscord #14343 10:35 ShadowBot https://github.com/minetest/minetest/issues/14343 -- Ambient light and server control for it by Andrey2470T 10:42 MTDiscord They want your pr to rot until it's incompatible through 2 release cycles for a lighting change with mainly stack values added in along with a simple shader change? 10:52 MTDiscord Well, are we in a feature freeze? 11:50 MTDiscord Risk of introducing bugs sounds like exactly what feature freezes are for. You get those merged in before the freeze so that you can shake the bugs out during the freeze. 11:51 MTDiscord Sometimes it's not easy to articulate exactly what kind of problems one expects, but when people say something like "this is especially fragile" or something, they generally have some scenario in mind. 11:53 [MatrxMT] andrey2470t: I don't know why I was thinking of the visual effects PR, which has already been merged, I'm sorry. If core devs think that it can be approved and merged within two days, then sure 11:55 [MatrxMT] jordan4ibanez: we're not in a feature freeze yet, but, considering that we're trying a new release cycle that doesn't allow delays, erring to the side of caution sounds like a good idea 11:56 [MatrxMT] To be clear, last freeze lasted.. A month? That's not doable anymore 11:57 MTDiscord Less than a month for an MT feature freeze? That does sound fast. Nice. 11:58 [MatrxMT] Yeah, it's two weeks, release is expected to be October 27 11:59 [MatrxMT] And Sunday's meeting should be about applying the new name, possibly 11:59 [MatrxMT] So.. Lot of things to manage 12:02 MTDiscord Bye bye Minetest, hello Game Creation Platform Formerly Known As Minetest 12:04 Desour or, in short gcpfkas 12:04 Desour gcpfkas.get_node(pos) 12:15 MTDiscord Zughy, could you move my PR back to 5.10 milestone? 12:18 MTDiscord It is not to embarrass the reviewers from looking into it now as they may really think it won't come to 5.10 and won't review it correspondingly now 12:26 MTDiscord And move it in 5.11 after these two days if within them it won't get merged though 12:40 MTDiscord I can give it another thorough re-review today. 12:40 MTDiscord I would be inclined to propose the following compromise: We merge it, but if it introduces non-trivial bugs that are noticed during the feature freeze, we revert it and try again in 5.11. 13:32 [MatrxMT] andrey2470t: sure thing, done! and I agree with luatic 14:56 nekobro Can a dev approve my elastic scrollbar + scrollbar clamp fix? 14:56 nekobro *approve on the roadmap 14:57 nekobro im hoping to get it out before feature freeze, or at least stretch it out, its not too big a change 15:15 sfan5 fixes are not covered by the feature freeze 15:18 nekobro Right, but it does offer a """feature""", being scrollbar elasticity. Im debating disabling it by default, but id like feedback to decide this, it looks nice and is good for mobile users 15:19 nekobro also opened an issue regarding anticheat, considering your recent merge 15:49 [MatrxMT] roadmap exists in order to push people to stick to it. Creating a PR that doesn't relate to the roadmap, writing "idc" in the "does this relate to a goal in the roadmap?" question and then insisting in here so that some core dev decides to adopt your PR is not the best approach 15:59 nekobro oh sorry i thought it was unrelated 15:59 nekobro I'm lazy with my PR descriptions sometimes, usually because i just started writing the actual code 16:00 nekobro that's my fault bro 16:01 nekobro i didn't know if i had to actually fill that in, because i considered it didn't fall out or into the roadmap 16:07 nekobro ill speak my mind off real quickly, but ive grown tired of those kind of PR templates. "Have you read our CoC?" "did you see our contribution guidelines?" "Is your change tested?" "Do you REALLY want this in?" 16:07 nekobro chances are, if im contributing something, ive already discussed it in an IRC or a discord, and if i havent, an upfront message would handle that better 16:08 nekobro when i submit a PR, i want simply: "This change fixed #7262984, etc etc. How to test:" The todo list and all that gets a little in-my-way 16:08 ShadowBot nekobro: Error: That URL raised 16:08 nekobro excellent bot 16:09 nekobro i understand you guys do it in good faith, but ive gotten so used to filtering out half of the messages in them now.. 16:44 MTDiscord nekobro: PRs that don't relate to the roadmap and don't get approval may get randomly closed 16:45 MTDiscord It's on you to argument how it relates to the roadmap (IMHO you should be able to make a case for your PR, so you wouldn't need explicit concept approval). 16:54 nekobro I understand herowl, but.. why do we ask the person opening the PR "how they follow the roadmap?" Last I remember the roadmap, its very small, says something about UI improvements, which unironically i believe my PR definitely falls under, but even then, why dont we just ask them in a markdown comment "Make sure to check the roadmap" instead of adding an extra bit to every PR" 16:55 nekobro s/unironically/ironically 17:00 nekobro Goal of the PR, and "if not a bug fix, why is it needed" feels repetitive. One should specify the goal if its not a bugfix. If its truly needed, then that is where elaboration comes into play 17:00 nekobro The todo is also a bit noisy, if a dev needs a todo, then it should be commented out by default in markdown, allowing them to uncomment it 17:02 nekobro todos are good for drafts, but im not sure if you can specify an initial draft pr 17:44 rubenwardy Contributors are expected to read the roadmap, that's what it's for 18:09 nekobro so why not put it as a comment? 21:53 MTDiscord I think I'll have to do the review tomorrow