Time Nick Message 05:45 MTDiscord Well, considering how the development goes slow now, it is unfortunately unlikely, yes. In any case the ambient light is the most possible feature to get in 5.9, since it is ready long ago and was reviewed many times. 09:25 sfan5 looks like we will never get 5.9 out if everyone comes up with "oh can you delay it by a month because I hope to work on something" 09:26 sfan5 but honestly this is not my problem, I have stated my opinion and reasoning on this already 09:38 sfan5 planning to merge #14538 later 09:38 ShadowBot https://github.com/minetest/minetest/issues/14538 -- [no squash] Expose OpenGL debugging as a normal setting by sfan5 09:40 MTDiscord Well, the ambient light PR awaits review tbh. It's not really "I hope to work on something". 09:55 [MTMatrix] I'm on the same page sfan5 is: it's better to release more often than stall everything because of a couple of nice features that would probably cause some uncatched bugs once merged - pressing development to haste because of the upcoming release 09:57 MTDiscord Really did I ask for delaying here ? I just said it would be nice if there are curtain circumstances and reasons for it (not due to my PR) since it would also give me enough a time and attempt to finish my planned API and rework the dual wielding with basing on it 09:57 [MTMatrix] and knowing the feature freeze date preemptively, would help people (esp. core devs) understand what it's actually doable without getting crazy and what it's not 10:04 MTDiscord Note dual wielding (which not a just nice feature, but very useful one) has been postponed many times since 2020. So does it worth to continue postponing it further? 10:09 MTDiscord Personally I would have a patience and wait the release longer to get more necessary features than without them. I mean also including the CDB redesign and gltf support too. 10:16 sfan5 consider: what would be the downside of releasing 5.9 now and 5.10 with the features you mentioned later? I can't see any. 10:17 sfan5 I'm not blaming you for mentioning when you have time to work on PRs, I'm just annoyed everyone keeps hinting at delaying 5.9 instead of ... you know just doing more frequent releases 10:25 celeron55_ there's no reason to ration releases in any way whatsoever 10:26 celeron55_ (as long as enough people are around to step through the release process for most platforms) 10:29 MTDiscord X.Y.0 releases are what I like to call: bug testing in production 10:30 MTDiscord sfan5: the downside is that people have to wait another release period for the features they want to appear in 5.10, which is why they are inclined to ask for them to be squeezed into 5.9 10:32 MTDiscord but i agree that we probably want to release 5.9 soon-ish, since there's already a decent amount of features and bugfixes. this will probably require postponing some features. 10:33 MTDiscord (where soon-ish means a month or two) 10:33 celeron55_ there is no "release period" other than the feature freeze, which is way shorter than the one month you guys seem to be talking about 10:34 celeron55_ and we have the process in place for the case where features are merged during a feature freeze, by using a dev branch. the limiting factor again is just whether the pace of development and amount of people working on stuff warrants it 10:36 celeron55_ just vouch for more frequent releases. it makes zero sense to vouch for postponing the next release for a time that's equivalent to multiple feature freezes 10:37 MTDiscord theoretically, there is no release period, but practically, something around half a year emerges 10:37 celeron55_ (eh, that's probably the wrong word) 10:37 celeron55_ (vote for, i suppose) 10:37 MTDiscord i agree that more frequent releases would be a good thing, but i'm not familiar with the manual work involved and to which extent we can reduce this 10:38 celeron55_ well, if people ask for the release to be postponed, what do you think will be the result? 10:38 celeron55_ you have to do the opposite. i think this is obvious 10:38 MTDiscord infinite postponing 10:38 celeron55_ the work involved to create a release can be lessened in two ways: 10:39 celeron55_ 1) just don't do the work. don't release for android, if the next release is in 1 month anyway 10:39 celeron55_ 2) automate more stuff 10:39 celeron55_ three: 10:40 celeron55_ 3) teach more people to do it 10:41 celeron55_ ideally the release process should be completely automated in the CI system but that's not always easy to do and it can result in lots of maintenance work of the CI system 10:42 MTDiscord What's stopping a release from happening this very second? 10:43 MTDiscord among other things there are a few regressions we would prefer not to release 10:44 ROllerozxa well the windows CI should be good enough to generate artifacts that can be used for releases now (excluding the DLL issues caused by the irrlichtmt merge). if the android CI generated an .aab file artifact in addition to the .apk artifacts then it could be used for releasing to google play 10:44 MTDiscord List the regressions, stop everything else, fix them, release it, everyone happy, and if they aren't that's just too bad 10:44 celeron55_ the release process starts by someone proposing to make the release. then a list of blocker issues are collected. if it's already known there would be blockers, it doesn't make a lot of sense to start the process 10:46 celeron55_ unless the blocking issues are small and can be obiously sorted out within a normal length feature freeze 10:46 MTDiscord If you start the process and make a big stink about the blockers, it brings attention to the blockers. The old carrot on a stick 10:49 celeron55_ all of this always requires someone to basically temporarily act as the "product owner" (or chairman of sorts) for the particular release, so that decisions can be made efficiently. it's never been done officially, someone just picks up the ball when they feel like it 10:51 celeron55_ i don't know if choosing the person officially would speed up the process or make everyone avoid it even more 10:52 MTDiscord Well if it's me, they're definitely going to avoid it. But who normally owns the "product"? 10:53 celeron55_ the core team as a whole has the responsibility of maintaining the coherence of the "product" 10:53 celeron55_ but the core team is a pretty bad chairperson 10:55 celeron55_ in an ideal world maybe i would have the time to do it, and indeed i might sometimes, but it would be irresponsible of me to set this project up in such a way that releases would be dependent of me. thus, i recommend not asking me 10:55 MTDiscord So if I were to become the face, everyone can just yell at me? 10:55 celeron55_ the right way to go is to identify the sore points and make the process more accessible 10:56 celeron55_ and, maybe to codify some kind of release leadership. i'm unsure about that. it's worth discussing 10:57 celeron55_ well if you ask to lead a release, the core team will surely give their vote about the proposal 10:58 MTDiscord Oof, I already know that answer. Hmm. @Lars how do you feel about attempting this with me? 10:58 celeron55_ i'd be fine with it, but i probably like reckless experiments more than the others... 11:02 MTDiscord Yes that would indeed be a wreckless experiment, I suppose someone will end up reading my interest in this and step in out of caution 11:03 celeron55_ it* 11:03 celeron55_ wait 11:03 celeron55_ no, it wasn't a typo 11:18 rubenwardy I'm all for more frequent releases. In our current state, the only feature that should stall 5.9 is SDL support. Everything else is optional, if it gets in it gets in. And I suppose we could switch back to the other input backends if we want to release and SDL is taking too long 11:19 MTDiscord jordan: wdym attempting this with you? i don't exactly have an abundance of time presently. i would not be opposed to you becoming "release leader" assuming due diligence. 11:21 MTDiscord Darn 11:43 [MTMatrix] So uhm.. Release June 1? 12:02 MTDiscord At this rate package managers won't even have to package version 5.8; they can skip directly to packaging 5.9. 😄 12:31 MTDiscord Debian is always going to be chronically slow 13:16 sfan5 rubenwardy: what do you mean by "SDL support" precisely? 13:16 rubenwardy anything required to get Minetest working with SDL in a stable release. Includes platform specific fixes. Does not include the sdl gamepads 13:19 rubenwardy also does not include touchscreen features unless fixing regressions 13:20 sfan5 as far as I'm concerned it works 13:20 sfan5 and I don't remember us tracking any related regresions 13:21 sfan5 (though inevitably those will crop up when more people start poking it) 13:21 sfan5 hm actually there's the "opening chat sometimes freezes the client for a moment" thing that I haven't tracked down 13:29 sfan5 opened an issue now so we don't forget 13:30 [MTMatrix] Regressions I'm aware of that should be fixed before a stable release with SDL: highdpi is broken on Windows (https://github.com/minetest/irrlicht/issues/173), some keybinds are broken (https://github.com/minetest/irrlicht/issues/207) 13:46 sfan5 "broken on windows" more like not implemented 13:51 [MTMatrix] but it worked before, at least the scaling thing 13:52 [MTMatrix] can you call a removed feature a regression? 13:54 sfan5 maybe 14:26 MTDiscord sfan5 is there a possibility to get minetest.generate_biomes included in 5.9 along with the multithreaded lua mapgen? Its rather part of the same feature imo 14:27 MTDiscord pull 14260 by gael 14:28 MTDiscord it was updated to support the multithreaded lua mapgen 14:38 [MTMatrix] I think that if we ask for yet another feature to add, sfan will kill someone 14:41 MTDiscord Ahem, animated gltf nodes 14:49 [MTMatrix] why not raytracing? 14:50 MTDiscord Both. In the same PR 14:52 MTDiscord sfan5, is the failing Visual Studio build you wanted someone to look at specifically the one built with SDL2? 14:52 MTDiscord its already fixed 14:53 MTDiscord 👍 15:10 sfan5 @mistere_123 if it is merged before feature freeze it will get in, if not then not 15:10 sfan5 anyway since the release process was being discussed the document is here https://dev.minetest.net/Releasing_Minetest 15:10 sfan5 if anyone sees room for improvement (simplification) please tell 15:36 MTDiscord I think apt is still at 5.4 15:39 MTDiscord Re releasing document: lgtm 16:10 sfan5 @josiah_wi the same checks are failing again so feel free to investigate again 16:11 sfan5 maybe a new vcpkg version could help 16:11 sfan5 uh nevermind it's just randomly aborting the build now?! https://github.com/minetest/minetest/actions/runs/8692140920/job/23836049865 16:12 MTDiscord I never expected more from Visual Studio. 16:12 MTDiscord sfan, it says TEST_GL_IDENTIFIER was not found. 16:13 MTDiscord Sorry, TEST_GL_ERROR, I mixed up words from the message. 16:16 MTDiscord If the compilation log weren't chock full of warning messages then it would be easy to find the one that says error:. 16:21 sfan5 huh 16:22 sfan5 well I can't tell what's wrong there 18:17 sfan5 pushing https://github.com/minetest/minetest/commit/38cacfa577a14be0b7b8f42484970ef234d44e38 soon 18:27 grorp FYI: I'm attaching a deps.zip file to https://github.com/minetest/minetest_android_deps/releases/tag/5.8.0 to make my 5.8.1 CI build work 19:14 grorp #14548 19:14 ShadowBot https://github.com/minetest/minetest/issues/14548 -- Backport 5.8.1 (Android-only) by grorp 21:59 rubenwardy the hypertext parser has no unit tests, glorious 22:00 v-rob I mean... it feels moot to test something that's so terribly and obviously buggy anyway 22:01 rubenwardy if it were unit tested it wouldn't be so buggy 22:01 rubenwardy anyway #14550 22:01 ShadowBot https://github.com/minetest/minetest/issues/14550 -- Allow quoting hypertext attribute values by rubenwardy 22:01 v-rob Like, I hate how \ will escape a bold tag, but \ will insert both the tag and backslash verbatim 22:01 v-rob It's not even just buggy, but totally underspecified how it should work 22:02 v-rob There's a reason I avoid hypertext like the plague :) 22:03 rubenwardy both of those should insert < without the \ 22:03 v-rob Last time I checked, it didn't. Or maybe I'm remembering a similar bug 22:03 rubenwardy yeah I think there's likely to be a similar bug in a different place 22:34 rubenwardy and #14551 (will probably merge as trivial tomorrow) 22:34 ShadowBot https://github.com/minetest/minetest/issues/14551 -- Hypertext: Fix missing space after single letter word by rubenwardy