Time |
Nick |
Message |
00:05 |
|
YuGiOhJCJ joined #minetest-dev |
00:39 |
|
proller__ joined #minetest-dev |
02:07 |
MTDiscord |
<exe_virus> Agreed, hence why I'm putting forward a more flexible approach than hard coding in larger versions of biome mappings |
03:19 |
|
Lupercus joined #minetest-dev |
03:28 |
|
beanzilla joined #minetest-dev |
04:00 |
|
MTDiscord joined #minetest-dev |
04:04 |
|
beanzilla joined #minetest-dev |
05:32 |
|
flux__ joined #minetest-dev |
08:22 |
|
Warr1024 joined #minetest-dev |
08:47 |
|
Warr1024 joined #minetest-dev |
10:31 |
sfan5 |
http://sprunge.us/vo5Gfe?diff pushing this soon |
11:05 |
|
proller joined #minetest-dev |
11:41 |
|
shaft joined #minetest-dev |
11:42 |
shaft |
LISTEN UP ENGINE DEVELOPERS. YOU FUCKED UP MT set_eye_offset and it behaves vastly different between 5.7/8 and the current dev build. We NEED your input to resolve how it should be handled for a mod and what is to be done about MT engine before 5.9 release. https://github.com/minetest-mods/ts_furniture/pull/20 |
11:53 |
[MTMatrix] |
<Zughy> I think you should insult us more, to obtain more authority and have us fix your issue in no time |
11:54 |
shaft |
It's your fault so :) Should I put :) behind every sentence from now on? Just imagine screeming_anime_girl.png next to it with a memecenter label at the bottom right. |
11:55 |
[MTMatrix] |
<Zughy> No, but you could fuck off with your manners, since we're all volunteering |
11:55 |
shaft |
Just don't take everything so seriously. |
11:55 |
MTDiscord |
<warr1024> Now that we have the protocol version bump in the release process, it should always be possible to detect which release somebody is running and work around any kind of behavior changes, even if they don't get caught or fixed in time for a release. |
11:56 |
MTDiscord |
<warr1024> There is no need to panic. |
11:56 |
[MTMatrix] |
<Zughy> warr1024: that doesn't seem fun though |
11:56 |
rubenwardy |
blaming people doesn't result in a constructive environment. Bugs happen. The thing to do is provide reproduction steps, not point fingers |
11:57 |
MTDiscord |
<warr1024> Lol, there is no need to NOT panic either. Do as you please 😄 |
11:57 |
shaft |
So I should put in a version check? Which function should I use? I know the behaviour started no longer being "broken" on 5.9 but when did it start? I know it's not working right in 5.8 and 5.7 but what about earlier versions? |
11:58 |
MTDiscord |
<warr1024> You should file a bug report. Then politely escalate it if it seems major, or it's getting too close to a release and it's at risk of getting missed. |
11:58 |
MTDiscord |
<warr1024> Then if it does get missed, the version check is a fallback plan. |
11:58 |
shaft |
But I want the mod to be fixed now. |
11:58 |
[MTMatrix] |
<Zughy> You should git bisect to find the commit at fault |
11:58 |
shaft |
And I don't wanna debug the engine |
11:59 |
[MTMatrix] |
<Zughy> I want to be rich, but people aren't going to give me money if I don't work |
12:00 |
shaft |
I already made a PR and it works with the latest released version of minetest. I did work |
12:00 |
[MTMatrix] |
<Zughy> Also, not even a company would fix a bug right away, so good luck |
12:00 |
[MTMatrix] |
<Zughy> Sfan already told you why that PR is not a solution |
12:01 |
shaft |
Can you please stop being passive aggressive toward me, Zughy? I said I'll put in version check. |
12:06 |
[MTMatrix] |
<Zughy> You also said you want the bug to be fixed right away, said that your PR is fine when it's not and approached us pointing fingers. So, again, good luck. It's not being passive-aggressive. Personally, this conversation is over |
12:07 |
shaft |
I said I want to fix the bug in the mod right away. |
12:07 |
shaft |
And I will |
12:08 |
|
definitelya joined #minetest-dev |
12:09 |
|
definitelya joined #minetest-dev |
12:09 |
|
definitelya joined #minetest-dev |
12:09 |
MTDiscord |
<warr1024> MT does not support detecting specific non-release versions, like down to the commit granularity. If it hasn't been released yet then it's not a "version" of MT yet. |
12:12 |
|
thelounge656 joined #minetest-dev |
12:12 |
|
wsor4035 joined #minetest-dev |
12:13 |
|
MisterE123 joined #minetest-dev |
12:16 |
|
Desour joined #minetest-dev |
12:37 |
shaft |
I just detect whether it's 5.7.0 or 5.8.0. You never release new minor versions after all anway. |
12:52 |
|
Desour joined #minetest-dev |
13:00 |
|
json joined #minetest-dev |
13:00 |
|
wsor4035 joined #minetest-dev |
13:02 |
Desour |
LISTEN UP ENGINE DEVELOPERS and other people reading this. I FUCKED UP MT CMAKE_BUILD_TYPE, AND AS A RESULT TOLD YOU UNTRUE STUFF about RelWithDebInfo performance |
13:02 |
Desour |
PR: #14600 |
13:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/14600 -- Reject invalid CMAKE_BUILD_TYPE values by Desour |
13:03 |
Desour |
it also explains why hotspot was suddenly no longer finding the symbols |
13:05 |
Desour |
and I noticed, in irrlicht we don't have CMAKE_CXX_FLAGS_config for configs other than Release and Debug |
13:05 |
Desour |
possibly also in other vendored libs, haven't checked |
13:06 |
Desour |
so, irrlicht wont be properly optimized, nor have debug symbols, if built with RelWithDebInfo |
13:06 |
json |
Hello! I'm using flatpak and I have a problem: even when I change the language in the settings, Minetest still uses English. Minetest version: 5.8.0; OS: Linux Opensuse leap 15.5. Thank you! |
13:07 |
shaft |
I put version check in https://github.com/minetest-mods/ts_furniture/pull/20 but sfan5 got bored of testing it, so it would be appreciated if someone where to test and merge PR. |
13:08 |
shaft |
*were to |
13:17 |
json |
By the way, this issue has already been reported: https://github.com/minetest/minetest/issues/13210. Apparently this is a long-standing problem |
13:18 |
json |
at least since version 5.6.1 |
13:18 |
shaft |
Use the Appimage https://github.com/An0n3m0us/Minetest-AppImages/releases |
13:18 |
shaft |
Appimage rules |
13:20 |
definitelya |
And goes back to talking to himself... |
13:21 |
shaft |
You mean me? It was directed at Json who is using the flatpak and having trouble with the language settings. They work with the appimage |
13:22 |
json |
OK |
13:24 |
[MTMatrix] |
<Zughy> json: yeah, that's pretty annoying, I've been having the same issues for years |
13:24 |
[MTMatrix] |
<Zughy> it either uses your system language or, if you change it, English |
13:25 |
[MTMatrix] |
<Zughy> *same issue |
13:25 |
json |
I'm just wondering: is this a Minetest or Flatpak problem? |
13:25 |
[MTMatrix] |
<Zughy> also, meeting in about 1:30h |
13:26 |
shaft |
It's a flatpak problem |
13:26 |
shaft |
A minetest flatpak problem but such issues are typical for flatpaks |
13:27 |
json |
Why? |
13:30 |
shaft |
Because of the "isolation" they do. They do some half assed containering. It typically doesn't really add anything in terms of security. Flatpak just isn't made for users of home computers. |
13:30 |
shaft |
Don't misunderstand: It works fine on home pcs but it isn't targeted at their use case |
13:31 |
shaft |
It used to brake themes too. |
13:32 |
json |
ok thank you |
13:32 |
|
Lupercus joined #minetest-dev |
13:32 |
json |
good bye |
13:54 |
|
Lupercus joined #minetest-dev |
14:02 |
|
proller joined #minetest-dev |
14:15 |
|
Fenrir24 joined #minetest-dev |
14:27 |
|
proller joined #minetest-dev |
14:42 |
|
Fenrir24 joined #minetest-dev |
15:00 |
[MTMatrix] |
<Zughy> dlin dlon, meeting time |
15:01 |
[MTMatrix] |
<Zughy> pinging sfan5, srifqi |
15:01 |
sfan5 |
I happen to be here |
15:03 |
MTDiscord |
<luatic> me too |
15:03 |
[MTMatrix] |
<Zughy> Hoping more core devs will show up, we have just one point: "Feature freeze when? May 12, release June 1? (Zughy)" |
15:04 |
[MTMatrix] |
<Zughy> (may 12 is when the next meeting is supposed to be) |
15:04 |
Desour |
last release, the feature freeze far too long, imo |
15:05 |
Desour |
it had to be enlonged because issues were not fixed in the expected time frame, and because some things breaking feature freeze had to be done |
15:05 |
rubenwardy |
Freezes are supposed to only be a week |
15:05 |
Desour |
so I would like it if we only enter feature freeze once the milestone is empty |
15:05 |
[MTMatrix] |
<Zughy> That will probably never happen |
15:07 |
pgimeno |
maybe it would be good to distinguish "milestone freeze" from "feature freeze"? |
15:07 |
[MTMatrix] |
<Zughy> Also, all the issues in the current milestone are bugs, more specifically regressions https://github.com/minetest/minetest/milestone/23 |
15:07 |
[MTMatrix] |
<Zughy> and there are just two features (PRs) |
15:10 |
sfan5 |
for me, feature freeze includes stopping accepting new features into milestone |
15:10 |
sfan5 |
we could enter that phase any time but I fear working through the regressions is going to be a while |
15:11 |
sfan5 |
(and to be honest I am not interested in working on the inventory regressions) |
15:12 |
Desour |
just for reminder, the feature freeze took almost 2 months, from 2023-10-15 (according to meeting notes <https://dev.minetest.net/Meetings#2023-10-15>) till around 2023-12-04 (release date according to blog) |
15:12 |
[MTMatrix] |
<Zughy> I'm asking that for two reasons: |
15:12 |
[MTMatrix] |
<Zughy> 1. I'd like to understand how feasible it is to feature the new content main menu section |
15:12 |
[MTMatrix] |
<Zughy> 2. it helps us understand what to do |
15:12 |
[MTMatrix] |
<grorp> let's simply revert #13146 then (imagine a "juanchi face" emoji here) |
15:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/13146 -- Inventory mouse shortcut improvements by OgelGames |
15:13 |
[MTMatrix] |
<Zughy> https://matrix.org/_matrix/media/v1/download/matrix.org/cQdiEaOxIAVBUHYOBtLcHKdB |
15:13 |
[MTMatrix] |
<Zughy> and embrace the hate |
15:13 |
[MTMatrix] |
<grorp> (that was a joke, therefore the juanchi face |
15:14 |
[MTMatrix] |
<grorp> but it looks like the original author is not interested in fixing the regressions either :( |
15:15 |
sfan5 |
if we find nobody to fix the regressions (or decide that they aren't so important after all) it may not turn out to be a joke |
15:15 |
pgimeno |
I was thinking of feature freeze as: "no feature PRs are merged" which would imply "all feature PRs that are in the milestone are bumped to the next version" - so that new features have time to be tested (which is the point of a feature freeze) |
15:16 |
[MTMatrix] |
<Zughy> I fear that this release doesn't offer much for modders |
15:16 |
[MTMatrix] |
<Zughy> if we also remove that, which improves UX, meh.. |
15:17 |
[MTMatrix] |
<Zughy> (looking at you, appguru, for #13987 👁️) |
15:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/13987 -- [pls do not squash :3] Allow limiting object observers by appgurueu |
15:17 |
sfan5 |
I understand the marketing pov but the primary goal of a release is to get pending fixes and features into the hands of users not to create something exciting. |
15:18 |
sfan5 |
see also: the "release early, release often" discussion |
15:18 |
sfan5 |
anyway |
15:18 |
[MTMatrix] |
<grorp> for modders, there's the new and exciting async mapgen API |
15:19 |
sfan5 |
my vote goes to we should enter soft feature freeze soon |
15:19 |
sfan5 |
where soft feature freeze = no new features, except those in milestone (no new stuff added ofc) |
15:20 |
Desour |
meh. features in the milestone are usually large features. blocking small features would be annoying |
15:20 |
sfan5 |
well the point is to avoid new regressions during freeze |
15:21 |
Desour |
then we should rather enter a freeze where we don't merge PRs that are likely to cause regressions |
15:21 |
Desour |
(at least as long as they are not on the milestone) |
15:23 |
sfan5 |
where's the difference to a feature freeze? |
15:24 |
sfan5 |
I don't get your intent here |
15:24 |
[MTMatrix] |
<Zughy> grorp: that's surely great news and it's been a huge amount of work, but not a lot of games use mapgen. On the contrary, something like entities invisible only for some players can be useful in a big plethora of genres; at least I think (in the end I don't use mapgen so I might not be impartial) |
15:25 |
Desour |
in a feature freeze, we'd block *any* feature PR. this is different from blocking non-dangerous features |
15:25 |
MTDiscord |
<luatic> would gltf be considered admissible under the one approval rule? |
15:26 |
sfan5 |
no |
15:26 |
Desour |
luatic: model formats are part of the modding api, afaik |
15:26 |
sfan5 |
a whole new model format is also anything except "relatively simple" |
15:27 |
Desour |
the reason why we want to do feature freeze is so that we can be sure to test that the release version is bug free, right? |
15:27 |
MTDiscord |
<luatic> well it is unlikely to break anything except itself, assuming it is half-decently secure ;) |
15:27 |
sfan5 |
yes |
15:30 |
Desour |
so, if we do it earlier, it does not mean that we can release earlier. we still have to fix the bugs (which will definitely take more than a week). it doesn't matter if we fix them in a feature freeze or outside |
15:30 |
sfan5 |
right |
15:30 |
[MTMatrix] |
<grorp> though a feature freeze may result in higher pressure to fix them fast |
15:30 |
sfan5 |
I suppose the secondary function of a feature freeze is that it sets a "deadline" on when stuff should be finished so we can actually releasre |
15:30 |
Desour |
therefore, I'd suggest we should find ways to make the bugs fixed faster, so that we can release earlier. and I don't think a freeze is the right tool for achieving this |
15:31 |
MTDiscord |
<luatic> we could just each pick a bug or two |
15:31 |
[MTMatrix] |
<Zughy> Also, don't we incurr the risk to have too much on our plate in 5.10? From what I recall, there is the experimental GUI/HUD by v-rob, ambient light, various visual effects, CDB redesign, gltf format and possibly more. The risk of bugs seem pretty big, but delaying some of these features doesn't seem great either. Hence maybe diluting them (even just one) into 5.8 wouldn't be so bad |
15:32 |
[MTMatrix] |
<Zughy> (*5.9 + grammar mistakes) |
15:32 |
MTDiscord |
<luatic> ambient light could make it into 5.9, it's relatively small and not that far from mergeability imo |
15:34 |
MTDiscord |
<luatic> it's something i'd very much like to still get into 5.9 for modders to play with in fact. i think it's relatively low risk, and has a good "bang for the buck" ratio. others and i have also already invested a good amount of time into reviewing and discussing it. |
15:34 |
sfan5 |
just want to note that we can release as often and with whichever features we want |
15:34 |
MTDiscord |
<luatic> yes, but realistically, will we? |
15:34 |
sfan5 |
the end result is not even much different if we were to release twice as often with half the features |
15:35 |
sfan5 |
dunno |
15:36 |
MTDiscord |
<luatic> it's a discretization problem. i want to minimize the time modders have to wait for features like ambient light that are effectively "already there", hence if possible, i'd like to squeeze them in before the feature freeze. otherwise, they'll have to wait for another entire release period (which in principle could be arbitrarily short but practically will be a few months). |
15:36 |
MTDiscord |
<luatic> anyways, merging #14319 in 15m |
15:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/14319 -- Fix object:punch(puncher, ... should allow nil for puncher by sfence |
15:39 |
Desour |
idea: to lure contributors into fixing milestone bugs, we could warrant them a special place in the credits as "release makers" or so |
15:45 |
sfan5 |
do we have a consensus when to aim for a release? |
15:46 |
sfan5 |
or just whenever it's ready? |
15:47 |
[MTMatrix] |
<Zughy> And, do we wanna try shorter releases? |
15:57 |
MTDiscord |
<luatic> (start of) June seems reasonable, though i can't estimate how long it'll take to get rid of the regressions |
15:58 |
MTDiscord |
<luatic> an implicit shorter release "cycle" seems like a good idea |
15:58 |
Desour |
+1 on both |
15:59 |
sfan5 |
agreed |
16:00 |
|
flux__ joined #minetest-dev |
16:06 |
[MTMatrix] |
<Zughy> Nice, if there is nothing to add, meeting is over |
16:26 |
[MTMatrix] |
<Zughy> Moved 5.9 milestone to June 2 (it's a Sunday), written down notes from today's meeting, created an internal discussion for the next one. Thank you all for participating |
16:26 |
|
Fenrir24 left #minetest-dev |
16:26 |
[MTMatrix] |
<Zughy> also reminder: vote for the new name |
16:31 |
|
flux__ joined #minetest-dev |
16:47 |
Niklp |
hi, https://github.com/minetest/minetest/commit/c524c52baa5456cff87127b3c4c41b5758b91c7a removed support for `set_physics_override(0,0,0)` which was never documented. I'm pretty sure it should be removed from the breakages.md file then (https://github.com/minetest/minetest/blob/72cb4e9bea803d6b300d095394e380c3674347c4/doc/breakages.md?plain=1#L14) |
17:29 |
Krock |
Hi. will merge #14586 in 15 minutes |
17:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/14586 -- Client: fix unknown texture upon shift-move to full inventory list by SmallJoker |
17:42 |
MTDiscord |
<josiah_wi> Was glTF discussed? |
17:44 |
Krock |
Niklp: undocumented features should not need any special treatment. it's the modders fault for using it |
17:44 |
Krock |
also: merging |
17:44 |
Krock |
@josiah_wi Not in this meeting from what I can see. |
17:47 |
MTDiscord |
<luatic> realistically, it will probably have to wait till 5.10, since we want to release soon-ish, it's a rather large feature and there are still a good bunch of regressions to be fixed (and some smaller features that are farther along to potentially get in); it does not qualify for the new one approval rule |
17:49 |
MTDiscord |
<josiah_wi> Yes, thank you. |
18:50 |
|
Noisytoot joined #minetest-dev |
18:58 |
|
Noisytoot joined #minetest-dev |
21:12 |
|
imi joined #minetest-dev |
21:51 |
MTDiscord |
<herowl> If we can get through with #14543 into 5.9, I could help fixing regressions. |
21:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus |
22:16 |
|
Lupercus joined #minetest-dev |
22:32 |
|
panwolfram joined #minetest-dev |