Time Nick Message 17:29 Krock Apparently a meeting is planned for today, in 30 minutes 17:30 rubenwardy !dev Meetings 17:30 ShadowBot Meetings - Minetest Developer Wiki -- http://dev.minetest.net/Meetings 17:35 rubenwardy merging #13550 in 10 17:35 ShadowBot https://github.com/minetest/minetest/issues/13550 -- Improve UX when no game exists and drop `default_game` by rollerozxa 17:36 erle > it will automatically pick the first non-devtest game 17:36 erle like, alphabetically or so 17:39 rubenwardy I believe alphabetically, although it may be an undefined order based on the filesystem 17:40 rubenwardy it's alphabetically, there's a sort 17:40 rubenwardy remember that the selected game is persisted though 17:42 erle yeah i think that's the only thing important 17:42 erle and if there is only one game, it gets selected, so ”single-game-launchers” may still be possible (right?) 17:43 rubenwardy yeah 17:43 erle i think it's a very loud step towards ”minetest is an engine” 17:43 erle so, congrats ROllerozxa 17:49 MTDiscord oh nice, it got merged. I'll go ahead and open the 2nd MTG debundling PR real quick 18:02 ROllerozxa erle: I'd assume it goes in alphabetical order, but the most important thing is that there is no `default_game` setting that is set to `minetest` by default but that it can adapt 18:03 ROllerozxa so if someone bundles the engine with their own game, that is what it will pick and it won't go into a gameless void 18:04 Krock Meeting time 18:04 Krock > Feature freeze? 18:05 Krock https://github.com/minetest/minetest/milestone/22 80% complete 18:05 srifqi what was our target date for the next release? 18:05 Krock there used to be the goal of 6 months release cycles, but better earlier than later 18:06 Krock 5.7.0 was in April, so the next would be due in October 18:07 srifqi 8 April to be exact, so it would be 8 October (in 20 days) 18:07 Krock was minetest_game yet defined to be dropped in 5.8.0? if so, #13800 would need a milestone 18:07 ShadowBot https://github.com/minetest/minetest/issues/13800 -- Migration path once MTG is no longer preinstalled 18:09 Krock adding the milestone just in case 18:09 srifqi due to recent commmit, it should be included in the milestone 18:09 Krock fortunately there's not too much waiting explicitly for 5.8.0 18:11 Krock unfortunately I was not very active in the Minetest Engine repository as of lately to judge whether there's PRs that should make it into 5.8.0 18:11 Krock so if you have some that are necessary, please add a milestone or let me know so that I would then add it 18:11 Krock (you = anyone participating in this meeting) 18:13 Krock There were a few new features which I could add to a first draft of the changelog to then judge whether a release would make sense 18:13 Krock so that we could discuss that latest in 14 days 18:15 MTDiscord MTG isn't debundled yet. If we decide to debundle it for 5.8.0, #13818 should be added to the milestone as well. 18:15 ShadowBot https://github.com/minetest/minetest/issues/13818 -- Debundle Minetest Game by rollerozxa 18:17 Krock I see. I will add it to the milestone since it's been mentioned a few times so that it's not entirely forgotten. However, the follow-up issue on the migration path should not be a blocker for the next release 18:17 Krock so a solution for this new issue should be provided too before the debundling change makes it into the repo 18:18 Krock changed the milestone to Oct 15 so that one meeting can be held before feature freeze 18:20 Krock > #13642 18:20 ShadowBot https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero 18:20 Krock I assume that's a general request for review, @wsor4035 ? 18:21 Desour I've recently wrote a comment there 18:21 srifqi ... which I agree with 18:21 Desour imo we need reproduction instructions, so we can review 18:21 MTDiscord @wsor 18:22 Krock I am just afraid that pulling bugfixes from the upstream Irrlicht repo will become even harder than it already is 18:22 Desour irrlicht dissolves anyway. rebasing upstream commits seems unrealistic 18:23 Krock in either case, I would like to have the git history preserved which also allows easy reverts and bisecting 18:23 Krock .. which seems to be basically impossible by what this PR intends to do 18:23 Desour oh, I thought we wanted to throw away the commit history 18:25 MTDiscord krock: basically a decide one way or another to import vs submodule/etc since no real dev input had been had on it 18:26 MTDiscord How would you preserve the commit history? By putting a huge amount of Irrlicht commits on top of the Minetest commit history? 18:26 Krock I wonder whether that is okay because the zlib/libpng license requires you to include copyright which is to my understanding also the committer's name and email? 18:26 Desour iirc, a submodule would only be temporary if we did that 18:26 Krock or am I misinformed about that? 18:27 Krock @wsor4035 I would be very much in favour of the git submodule approach, although I also have seen arguments against that. e.g. doubled effort for PR creating 18:28 MTDiscord personally same 18:30 MTDiscord the other reason i asked zughy to put it on is the current situation is a bit of a mess, and confuses a lot of (mostly non technical) people for building minetest/getting version right 18:31 erle well that's the issue of having a library that is not really a library, but some other component hat must be updated in lockstep 18:31 Desour Krock: irrlicht/LICENSE doesn't say anything about commits. and a quick web search didn't reveal anything either 18:32 srifqi Krock: a file containing a list of committers' name + email alongside the license text and a notice about its "acquisition" should be fine 18:32 Desour anyway, we'll keep the irrlicht repo anyway, I assume. so we could just add a note that the old parts of the commit history exist there 18:32 srifqi set it to public archive perhaps 18:35 nrz_ It's also possible to have license and contributor file keeping it 18:35 Krock srifqi: right, that should solve any such issue (if my concern is valid at all) 18:36 sfan5 fwiw keeping commit history was absolutely not my plan 18:36 sfan5 the irrlicht repo also only contains the last thousand or so revisions, there's a cutoff 18:36 sfan5 so for full history we'd have to reference irrlicht's svm 18:36 sfan5 svn* 18:37 Krock oh, I did not realize that. so we're already half-way there to trash the history anyway. okay then 18:40 Krock so copypasting IrrlichtMt into Minetest is the consensus? If not, would a poll for import vs copypaste be desired? 18:41 Krock s/vs copypaste/vs submodule/ 18:42 srifqi i support the import process after Desour's comment has been addressed 18:43 Desour_ copy-paste > submodule from my side. (idk if there's a realistic good third way) 18:43 erle subtree? 18:43 erle Desour_, https://www.atlassian.com/git/tutorials/git-subtree 18:43 Krock the nicer submodule? 18:43 MTDiscord its worse 18:44 Desour_ I know that exists, but idk if it's good 18:44 sfan5 submodule is just the current situation but nicer 18:44 sfan5 copy-paste is the end goal, there isn't really a way around it 18:44 erle true 18:44 Desour_ but iirc you still have to mess with new commands, and can't just mix up the files between both parts 18:45 erle subtree is copy-paste but nicer, not? 18:46 erle i mean it's mainly a merge strategy to nest repositories 18:46 Krock the issues that are to be addressed are: avoiding out-of-sync situations for the lockstep (copypaste and git submodule can do that) and less PR efforts (copypaste can do that). subtree does not appear to appear to solve that 18:46 Desour_ somehow rebasing all irrlicht commits on minetest in some way could also be theoretically a way. but it might be ugly, and we don't have old irrlicht commits anyway, as mentioned above by someone 18:47 Krock AFAIK you cannot rebase without a common git commit. copypaste is the only way 18:47 erle you can synthesize a history for old irrlicht commits from svn and graft the new history on it ig 18:47 erle like using git-svn clone 18:49 Desour_ anyway, it wouldn't be worth the effort, imo 18:49 erle i actually thought to do that for a possible custom irrlichtmt in case the threats of “we well drop support for your platform” become true, but i guess it is pointless to even think about that given that it will not stay separate for long now 18:51 Desour_ *awkward silence* 18:51 pgimeno I am still maintaining a copy of the full Irrlicht in git form 18:53 Krock answered to the PR to clarify the status of it 18:53 erle pgimeno do you have some kind of shim that manages to bridge the irrlicht-irrlichtmt gap maybe? 18:54 Krock thanks for the inputs so let's continue 18:54 Krock > #13700 18:54 ShadowBot https://github.com/minetest/minetest/issues/13700 -- Android Java: Add some final by oong819 18:54 MTDiscord The copy-paste approach seems like the best approach to me. 18:54 nrz_ Copy paste i's definitively better, but you Can also import code in a subfolder with history 18:55 Krock nrz_: If that's possible it would address one of Desour's comment points. Please give details about that in #13642. 18:55 ShadowBot https://github.com/minetest/minetest/issues/13642 -- Import Irrlicht by numberZero 18:55 srifqi about that Java PR, my suggestion is to add simple code style guidelines for Java language (or languages in Android ecosystem) 18:56 sfan5 if we want to bring out java code forward we should migrate it to kotlin 18:56 srifqi Android Studio has a built-in code formatter that we can use 18:56 sfan5 all in all it doesn't really matter however 18:56 rubenwardy I love Kotlin but also we have so little Java code it doesn't really matter 18:56 Krock can the C++ style rules not be applied roughly to Java? 18:57 rubenwardy no, our C++ style rules are shit 18:57 rubenwardy just use Android Studio's styler 18:57 pgimeno erle: no I don't 18:57 Krock now I see the PR. indeed, it needs a specific set 18:57 Desour_ (Krock: to be clear, in that one comment point I suggested that you don't need to import the whole history and instead look at the irrlicht repo as soon as you reach the commit that imported irrlicht) 18:57 pgimeno erle: but it should be possible to rebase it with some trickery 18:57 rubenwardy (the best code styles are done by the IDE so you never need to think about it) 18:57 srifqi while Java and C++ are in the same "family", it can be different in terms of style rules 18:57 rubenwardy s/the IDE/a tool/ 18:58 Krock ( Desour_: well at the same time you want a solid reproduction step which would be the case if the trees merged. Both ways would be possible, I suppose ) 18:59 MTDiscord srifqi: Can you run the Android Studio formatter from the command line? 18:59 rubenwardy yes 18:59 Krock rubenwardy: so a simple "use Android Studio's styler" would already suffice as Java rules? 18:59 Krock oh that's a cool thing. would be nice if the command line is documented in the wiki as well 19:00 rubenwardy well, whatever code formatter we use should run as a gradle target as well 19:00 MTDiscord I don't think this is anything any styler currently does (deciding whether or whether not to use final) 19:00 MTDiscord because final communicates intent not to change a variable / override a function / extend a class, it's not "just style" 19:01 grorp Hello, I'm a real IRC user now :) 19:01 srifqi hello 19:01 MTDiscord you could slap final onto everything that is de facto not changed, but that would make it harder to change variables / override functions / extend classes 19:01 MTDiscord so I'm not too fond of the approach that PR took, though many of the variables there seem to have the intent of being final 19:01 Desour_ the C++ code could also use some final btw. 19:01 srifqi yes, that PR just inspired me about making a code style for Android code 19:02 srifqi i don't support that PR 19:03 Krock I don't see the point of using final when we're in full control of the source code anyway and that apps are generally isolated on Android devices, so I don't think that it's necessary at all 19:03 srifqi grorp: Android Studio (or Intellij IDEA) has bin/format for that purpose 19:04 Krock is anyone interested in providing a first draft of coding rules? 19:04 MTDiscord I agree that the motivation behind the PR was poor. The main reason to use final is, as said, to communicate intent such that a dev who later on swoops in knows that something is not supposed to be modified. 19:06 Krock no replies, so I'll just note that volunteers are welcome to propose simple rules for the Java part 19:07 srifqi currently, we only inherit Android classes (no inheritance from our own class). we might add that when we do inherit our own class) 19:08 rubenwardy `final` isn't about security, you can override it using reflection. So being in full control or not doesn't make a different 19:08 srifqi Krock: my draft would be "The coding style used for Java and other languages in Android app ecosystem is the same as coding style used by Android Studio." followed by steps to format code in IDE and using command line 19:09 Krock so I'll note this down in https://dev.minetest.net/Java_code_style_guidelines as a starting point 19:10 Krock or rather "Android_code_style_guidelines" in case Kotlin is used, perhaps? 19:11 srifqi since we only use Java for Android purposes, Android code style guidelines is better 19:12 srifqi that might include Java and Groove language 19:12 srifqi ... and XML, too 19:14 srifqi s/Groove/Groovy 19:15 srifqi oh, thank you for creating the page 19:15 Krock -> https://dev.minetest.net/Android_code_style_guidelines 19:15 Krock next up: #13583 19:15 ShadowBot https://github.com/minetest/minetest/issues/13583 -- [discussion] Define a policy for raising our dependencies' versions 19:16 Desour_ I've written a draft locally, but it's unfinished 19:17 Krock okay, so I think it would be good to wait for that and then discuss the proposed points. The issue does provide reasonable suggestions 19:17 erle Desour_ is that also relevant to *security* upgrades for old platform? 19:17 srifqi Desour_: i thank you for that. i was wondering whether somebody is writing a draft 19:17 Desour_ https://github.com/Desour/minetest/tree/dep_upgr_policy 19:18 Desour_ erle: if you're referring to patch releases, it's not related to that at all 19:18 Desour_ srifqi: sry for being silent about it. I wanted to finish it but haven't found motivation 19:20 erle Desour_ i mean library version upgrades when a dependency has a security issue. no idea if ubuntu “support” actually means backporting all security fixes or not. 19:20 srifqi no, it's okay. i can understand that 19:20 Krock Desour_: in general I think that policies should be written neutral without any "you/we/whatever" mention. Furthermore, list your proposed Ubuntu LTS strategy. be clear where exactly we draw the line 19:20 Krock we'll check the PR when you are ready 19:21 erle Desour_ the ”prefer minimum” thing is good, unless there are security issues that are not addressed i think 19:22 Desour_ ah, that's what you mean. if a distro ships an old version without security patches, we are not to blame just because that version happens to work 19:24 Krock Desour_: would you like to have additional input or can you work with that? take your time. 19:24 Desour_ I have enough input, thx :) 19:25 Krock great! so let's continue with #11016. 19:25 ShadowBot https://github.com/minetest/minetest/issues/11016 -- Dual Wielding by LizzyFleckenstein03 19:25 Krock > I'd suggest to prioritise MTG removal and postpone this feature to 5.9, 19:26 sfan5 PR probably needs a second look, I didn't have time/energy yet 19:26 Krock well in the current state it is basically WIP, so it might be better to not only remove the milestone but also mark the PR as draft 19:26 Krock the old issues aren't addressed to my knowledge 19:27 erle were the old issues that this introduces an easy dupe or was that a different approach? 19:27 Krock implementing this will made the API somewhat messy to preserve mod compatibility, which is rather unfortunate 19:28 Krock erle: no, it's about mods not expecting the offhand while calling get_wielded_item() 19:28 erle ah 19:29 erle what i don't get – which part of dual wielding *needs* engine support? like why can't it be faked in a mod easily. 19:29 Krock the visual aspect for one (left side wieldhand) 19:29 erle and gameplay-wise? 19:30 MTDiscord there is no keybind for switching hands or stuff like that 19:30 MTDiscord and basically the only configurable keybind we have is aux1 19:30 Krock to place the so-called offhand node, but that could be implemented in mods, though. 19:30 erle yeah, that's rather easy ig 19:30 erle (don't quote me on this, i never done it, i may be totally wrong) 19:31 Krock I might already have said that I would support a skimmed-down version of that PR which only introduces a new wieldhand visual which depends on the optional player slot 19:32 Krock modders could then demand an aux2 hotkey or whatsoever to make better use of this visual feature 19:32 erle indeed 19:32 erle did you say that to lizzy in particular? 19:32 Krock correction: that would need to specify the hand animation for placing 19:32 erle Krock are you aware of any mod that tries faking it btw? i'd be interested how far ppl got 19:33 erle also i think the proposal is sensible, new slot, new visual 19:34 MTDiscord I am aware of such a mod which uses the first person attachments, I think. IIRC it was by T. Affeldt (TestificateMods) 19:34 MTDiscord https://content.minetest.net/packages/TestificateMods/offhand/ 19:34 Krock erle: I don't think any mod has implemented that yet reasonably because the HUD API does yet not support placing (wield)meshes onto the screen 19:34 erle ah, so we only get stuff like shields then 19:35 srifqi i agree about converting it to draft since the author clearly stated that there are some todos to be worked 19:35 srifqi ... and it's been 6 months, too 19:35 Krock alright 19:35 erle srifqi maybe ping the author too? i'll tell her when i see her on irc anyway 19:36 erle Krock, also i think if you attach a fake node mesh to a player that you generate on the fly there is no way to make it so that *you* see it but other players do not, right? unless … fuckery with dynamic media? :D 19:36 srifqi does converting to draft not ping the author? 19:36 erle no idea, lots of stuff does not ping anyone (at least via email) 19:36 Krock it should notify them 19:37 srifqi the label already tells that actions are needed, too 19:38 Krock alright 19:38 Krock > #13764 19:38 ShadowBot https://github.com/minetest/minetest/issues/13764 -- Refactored the liquid system, and added an optional feature for liquids to flow to the next slope. by cosin15 19:38 Krock concept approval question 19:39 Krock it does look very unique 19:40 srifqi i'm going to bed for now (02:40 am here) 19:40 Krock gn srifqi 19:40 Desour_ exactly mirroring the min-ec-raft's liquid physics would be hard probably. I've seen that video, it's super buggy 19:40 Krock the filling up of flowing liquids when hitting a dead end does have a better appearance than what's currently implemented 19:41 Krock regardless I believe the current code is somewhat optimized for speed throughout the years 19:41 Krock s/throughout/over/ 19:41 grorp I'm going to bed, too. Bye. 19:42 Krock good night. 19:42 Desour_ gn u2 19:42 erle having poked a bit around the liquid system myself i want to say two things: first if that thing is really bug-for-bug-compatible, it's great and will not destroy any user worlds. second, the new mode looks nice. it needs to be opt-in though. third: writing unit tests for that kind of thing would be amazing! 19:42 rubenwardy apparently MTDiscord too 19:42 Krock MTDiscord went to sleep as well 19:42 erle three things 19:42 erle [spanish inquisition meme intensifies] 19:42 sfan5 we could change the meeting time next time, since we no longer have anyone from the american continent attending (this was the reason IIRC) 19:43 MTDiscord I think it would be fair to ask the author to ensure that this introduces no performance regression. 19:43 Krock sfan5: sure. a few hours earlier would also be welcome from my side 19:44 Krock srifqi might like to have it at least 4 hours earlier to attend 19:45 Krock I'll ask them in the discussion of today's meeting 19:53 Krock no additional opinions on the PR? if you have some, please leave them there so that they're not working on a feature that might turn out to be undesired 19:54 Krock > #13789 last one for today 19:54 ShadowBot https://github.com/minetest/minetest/issues/13789 -- Fix liquid falling if in "float" group, fixes #13782 by kromka-chleba 19:54 rubenwardy <+Krock> > #13764 19:54 ShadowBot https://github.com/minetest/minetest/issues/13764 -- Refactored the liquid system, and added an optional feature for liquids to flow to the next slope. by cosin15 19:54 rubenwardy the outcome here is either to replace "Roadmap: Needs approval" with "Supported by core dev", or close the PR 19:54 rubenwardy same for the other one 19:55 Krock oh right. totally forgot about the original purpose of the talking point 19:56 Krock it does look interesting to me 19:56 sfan5 my opinion: idk 19:56 sfan5 if we're tending towards no maybe the author can PR the refactor first and try again then 19:57 Krock is that roughly how water is propagated in Minecraft? 19:59 Desour_ I haven't ever looked much into mt's liquid system. and I wouldn't want to open a can of worms that is a liquid system with new rules that can break in so many different ways, especially if those rules are not exactly specified. so no support from my side 19:59 Krock master and this PR look a bit messy. not much gained code quality wise 20:00 MTDiscord I would agree with sfan5 here, the refactor should be cleanly separated from the new feature. IMO such a refactor also needs to have rigid testing to ensure that this introduces no regressions, including performance regressions. 20:01 Krock so let's say refactor first, feature later? 20:01 celeron55 i think it's fair to require any refactor+feature to be split into first a refactor, then a feature (understanding the caveat that often it can be too much to ask and it will be dropped) 20:01 MTDiscord (I don't have anything to say) but I would agree with refactor first, feature later. 20:02 erle wasn't there something from the author along the lines of “if you promise you accept it, i'll make a test suite for the existing water” ? 20:07 Krock updated the comment. shall I keep the PR open so that they can adapt or just close? 20:07 Krock ^ rubenwardy 20:15 Krock by the way - any opinions on #13789 ? If there are no objections I'll remove the concept approval needed label 20:15 ShadowBot https://github.com/minetest/minetest/issues/13789 -- Fix liquid falling if in "float" group, fixes #13782 by kromka-chleba 20:20 Krock alright. thank you for lasting this long. I added the meeting notes to the wiki. Meeting done.