| Time |
Nick |
Message |
| 01:29 |
|
ivanbu joined #minetest-dev |
| 02:40 |
|
Lupercus joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:42 |
|
flux__ joined #minetest-dev |
| 05:13 |
|
d0p1 joined #minetest-dev |
| 05:20 |
|
MTDiscord1 joined #minetest-dev |
| 05:45 |
MTDiscord |
<andrey2470t> 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. |
| 06:51 |
|
v-rob joined #minetest-dev |
| 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 |
<herowl> Well, the ambient light PR awaits review tbh. It's not really "I hope to work on something". |
| 09:55 |
[MTMatrix] |
<Zughy> 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 |
<andrey2470t> 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] |
<Zughy> 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 |
<andrey2470t> 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 |
<andrey2470t> 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 |
<jordan4ibanez> X.Y.0 releases are what I like to call: bug testing in production |
| 10:30 |
MTDiscord |
<luatic> 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 |
<luatic> 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 |
<luatic> (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 |
<luatic> 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 |
<luatic> 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 |
<luatic> 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 |
<jordan4ibanez> What's stopping a release from happening this very second? |
| 10:43 |
MTDiscord |
<luatic> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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 |
<jordan4ibanez> 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:09 |
|
Lupercus joined #minetest-dev |
| 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 |
<luatic> 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 |
<jordan4ibanez> Darn |
| 11:24 |
|
imi joined #minetest-dev |
| 11:42 |
|
turtleman joined #minetest-dev |
| 11:43 |
[MTMatrix] |
<Zughy> So uhm.. Release June 1? |
| 12:02 |
MTDiscord |
<josiah_wi> 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 |
<wsor4035> 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] |
<grorp> 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] |
<grorp> but it worked before, at least the scaling thing |
| 13:52 |
[MTMatrix] |
<grorp> can you call a removed feature a regression? |
| 13:54 |
sfan5 |
maybe |
| 14:26 |
MTDiscord |
<mistere_123> 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 |
<mistere_123> pull 14260 by gael |
| 14:28 |
MTDiscord |
<mistere_123> it was updated to support the multithreaded lua mapgen |
| 14:38 |
[MTMatrix] |
<Zughy> I think that if we ask for yet another feature to add, sfan will kill someone |
| 14:41 |
MTDiscord |
<jordan4ibanez> Ahem, animated gltf nodes |
| 14:49 |
[MTMatrix] |
<Zughy> why not raytracing? |
| 14:50 |
MTDiscord |
<jordan4ibanez> Both. In the same PR |
| 14:52 |
MTDiscord |
<josiah_wi> sfan5, is the failing Visual Studio build you wanted someone to look at specifically the one built with SDL2? |
| 14:52 |
MTDiscord |
<wsor4035> its already fixed |
| 14:53 |
MTDiscord |
<josiah_wi> 👍 |
| 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 |
<herowl> I think apt is still at 5.4 |
| 15:39 |
MTDiscord |
<herowl> Re releasing document: lgtm |
| 15:58 |
|
flux__ joined #minetest-dev |
| 16:08 |
|
flux__ joined #minetest-dev |
| 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 |
<josiah_wi> I never expected more from Visual Studio. |
| 16:12 |
MTDiscord |
<josiah_wi> sfan, it says TEST_GL_IDENTIFIER was not found. |
| 16:13 |
MTDiscord |
<josiah_wi> Sorry, TEST_GL_ERROR, I mixed up words from the message. |
| 16:16 |
MTDiscord |
<josiah_wi> 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 |
| 17:24 |
|
v-rob joined #minetest-dev |
| 18:17 |
sfan5 |
pushing https://github.com/minetest/minetest/commit/38cacfa577a14be0b7b8f42484970ef234d44e38 soon |
| 18:26 |
|
grorp joined #minetest-dev |
| 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 |
| 20:24 |
|
v-rob joined #minetest-dev |
| 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 \<b> will escape a bold tag, but \<blahblah> 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:32 |
|
panwolfram joined #minetest-dev |
| 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 |
