Time Nick Message 01:49 MTDiscord I can be benevolent, but absolutely don't have the time or the git history to back up my credentials publically 01:49 MTDiscord maybe in a couple years/decade 02:15 MTDiscord What if Rubenwardy was the trusty c55 sidekick? 05:04 erle we need to revise the rules btw, there should be a lead core-developer role and their approval counts for 2. 05:05 erle i think you have not understood the function of code reviews 06:18 celeron55 i think what a lead core developer would have is basically a 2-vote concept approval, i.e. they could override the roadmap at will 06:18 celeron55 but a code review is needed as erle says 06:20 erle i think what the triaging spree of Zughy[m] proves is that more cooperation is needed, not a stronger leadership 06:21 celeron55 a lead core developer also could/would have the right to add or remove core developers 06:21 erle that surely would be fun haha 06:22 erle can wuzzy be lead core developer? “more responsible and more consistent on the long run than anyone else” ;) 06:24 celeron55 as a productive programmer i wouldn't be very exited from leadership and creative duties like that 06:24 celeron55 they take time away from actually implementing things 06:24 celeron55 excited* 06:25 erle additionally, good programmers are not good project managers, most of the time 06:25 erle like, i know exactly one person like that (minute of MNT UG) 06:25 erle and vice versa (i know a bunch of good project managers that are mediocre programmers) 06:26 celeron55 frankly i probably am a better programmer than a project manager 06:28 erle also, better leadership is not always stronger leadership. you can see it in mineclone2, which is much better off under leadership of cora than fleck (and i think fleck would agree here). she is much better at coordinating people. 06:28 erle “leadership” as in she is the maintainer. 07:29 Zughy[m] maybe it's the time Pyrollo gets removed 07:52 nrz tbh, regarding lead core developper, we have various developers skills in the core engine team but we don't have a very senior dev here i think, we are all almost good, but there is no excellent dev with very high C++ architectural skills, it's hard to define who is the lead dev. And in software teams lead dev have the same approval rights as other, it's more a maturity concept and organizational role than a bypass role ? (i'm w 09:00 Zughy[m] #11499 should have those two issues linked (I can't edit messages nor link them myself) 09:00 ShadowBot https://github.com/minetest/minetest/issues/11499 -- Night vision by x2048 09:55 erle nrz as i see it, several people are excellent at very specific topics, without being proper generalists, which is a pretty normal state of affairs for a big software project. 09:56 paradust sfan5: Do you need anything from me on the 3 irrlicht changes? Or the deSerializeJsonString? Did you want me to be reviewer/approver for it? 10:01 sfan5 the 3 irrlicht PRs (or to be exact the minetest counterparts) are waiting for another coredev to give them their approval so they can be merged 10:02 sfan5 you can make review comments on or test mine (or any other) PR if you want but it won't formally count towards mergability 10:09 paradust got it, thanks 10:18 nrz erle, we have feature specialists yeah, but not a C++ lead dev which is able to re-architecturate easily core engine ? 10:18 nrz sfan5, give me ids (i don't see the bot links on discord matterbridge) 10:19 erle nrz even if we had – it's *really* hard to majorly re-architecture stuff if everything is cobbled together and bolted on over a decade. 10:19 erle but as linux shows, you can get away with that kind of thing. no one *needs* to understand every single part of the final artifact to have it reasonably work well. 10:20 nrz or more than a decade, i already changes some things in the engine to have better POO, but majority of code is a bit too tied to the Server/Client/Env, making it difficult to isolate/test 10:21 erle i think the most important thing in such a project is that people try to not overestimate their own capability to judge something they have only casual experience with. 10:21 erle (it happens all the time, with everything, in about every project) 10:21 sfan5 nrz: https://github.com/minetest/minetest/pull/12263 https://github.com/minetest/minetest/pull/12301 https://github.com/minetest/minetest/pull/12313 10:31 nrz ok for 12301 10:31 nrz we are trying to remove irrlicht bindings one by one from minetest ? 10:35 sfan5 the idea is to get rid of Irrlicht's custom containers 10:35 sfan5 ...also you can't merge the PR yet 10:35 sfan5 it breaks the build 10:35 sfan5 either one or all of them 10:35 sfan5 and the irrlicht changes too, at the same time 10:36 sfan5 nevermind the std::map one should be fine on its own 10:37 nrz arf i merged, my bad 10:37 sfan5 no it's okay actually 10:37 nrz the third i commented, and saw it break build 10:37 sfan5 just not the other ones :) 10:41 nrz yeah np ? 10:44 sfan5 nrz: the build will be fixed when I tag the next irrlichtmt release, so that's not an obstacle 10:45 MTDiscord Re: having a lead developer who doesn't need concept approvals but still needs code reviews ... this sounds backwards to me. Most of the serious flaws I've seen introduced into software are at the concept level rather than the code level. I usually seek feedback on ideas, whereas code is just a detail I can fix later if needed. 10:51 kilbith RE: lead dev - long time ago, hmmmm was merging PRs on his own w/o code reviews 10:52 celeron55 during that time all core devs had an area where they could merge without code reviews 10:52 celeron55 and it resulted in stupidly bad code 10:52 celeron55 we were fixing bugs created during that time still a few years ago 10:53 MTDiscord Code reviews CAN be done well, but MT code reviews are generally too detailed. When I do them for other projects I mostly look at the architectural impact of the changes, i.e. what components are affected and what interfaces and interactions are changed. Correctness is mostly a job for testing, and stuff like formatting standards are up to the formatting tools and I just automatically run that stuff at merge time. 10:54 kilbith yes that's also true 10:55 kilbith I remember sapier directing the GUI area pretty badly 10:56 kilbith and as of today, we still inherit from his broken scaling code 10:56 celeron55 well there's no need to name names 10:56 celeron55 bad rules are not the core dev's fault 10:56 celeron55 or methods 10:56 celeron55 on that level 10:58 MTDiscord In projects I lead I don't always expect to fully understand contributed code, because if I understood the problem well enough to understand the solution, I probably wouldn't have introduced the problem and then had to have somebody else fix it for me in the first place XD. Rather than worry about making everything all correct all the time, I balance in a lot of internal bulkheads to ensure that problems can be isolated to specific 10:58 MTDiscord sections, I assume that any piece of code CAN be bad, and I stay prepared to replace any part that causes me trouble. 10:59 MTDiscord As a result I worry more about which code someone touches more than what they did with it, and I worry more about whether code's job can be understood and whether the code can be easily replaced, rather than how beautiful the code itself is. 11:01 MTDiscord I know that code reviews with this philosophy can be very fast. I can't speak to other approaches one way or another ... though if there are multiple reviewers who don't agree on an architectural philosophy, that seems like it'd create big problems. 11:12 erle that is an unusual approach indeed. for me, if i do not understand a solution, then the code is bad. it is, after all, written for humans (i.e. the people who want to change it later). 11:13 erle if i do not understand a solution *on my own project* i mean 11:17 rubenwardy No matter how good the dev is, they shouldn't be merging without code review. But I think generally merging with 1 review and 1 concept approval would be fine, as long as the reviewer is not the author and the PR isn't too big. We basically already have this with PRs made by core devs 11:19 MTDiscord I mean if what you want is efficiency, then having someone whose job is more or less JUST reviewing, and handling merges and the downstream consequences of those, instead of trying to implement novel changes, would make the PR pipeline run a lot faster. 11:20 kilbith torvalds is merging code on his own in the kernel 11:21 MTDiscord Especially if you do that in a tree structure instead of just a single-tier star topology ... instead of having everyone fighting to get PRs merged into minetest, allow a bunch of "minetest next-gen" forks, each with a project manager who focuses on an area of interest, who basically pre-curates and pre-integrates smaller changes from the community into big ones. 11:21 MTDiscord Yeah, what I'm talking about is more or less like a Linux kernel structure. We don't quite have the same scale, but it can be done on a smaller scale. 11:22 MTDiscord The nice thing about the "specialized forks with individual curators" thing is that we don't even need the core devs to set up that kind of structure, it can just naturally form... :-) 11:22 erle Warr1024 you already have specialized forks, but all the CSM improvements are not well-liked. :P 11:24 erle regarding reviews: again, “you can do reviews but it will not count for anything” is not very motivating. 11:24 MTDiscord Code review processes won't solve political problems either. If you can't sell the feature then it doesn't matter how good the code for it is... 11:25 rubenwardy reviews that "don't count" still help when it comes to code quality 11:27 MTDiscord Project roles right now are focused around permissions, like permissions to edit issues, or permissions to merge. They don't do a good job recognizing and communicating to the broader community when somebody has earned the trust to do certain things, like offer a code review that actually counts for something. 11:28 MTDiscord In a small group, you don't need tools to manage that kind of trust, but in a larger community like this, where there are a lot of people involved who haven't met certain other people involved, you need some system to help carry that trust around. 11:29 sfan5 it's possible to do primarily architectural reviews instead of code reviews but you risk importing lots of tiny spots where the code could be more efficient, something works but is easy to mess up in the future, unportability, etc. which someone then has to clean up at some point later (usually after it has caused a bug) 11:30 sfan5 depending on the scope and size of PRs I adjust my reviews to skip over details and judge the full picture but generally it's important to me that we have well written code 11:30 kilbith I still do have the impression that everything rests on sfan5's shoulders and he shouldn't have to take that much responsability 11:31 MTDiscord Right now, being a core dev means you're trusted to do code reviews, hold commit/merge permissions, have control over the issue tracker, and are expected to review code, write code, triage issues, attend meetings ... and if you're not a core dev (aside from the new triager role) you mostly just don't have any power, and all you can do is submit issues/PRs and pray, because every non-core-dev community member's trust level is assumed 11:31 MTDiscord to be basically the same unless the issue happens to be reviewed by someone who knows you (and they read the submitter's identity). 11:33 MTDiscord I guess I could say that it's fairly unimportant to me to have well-written code. Ideally I think code should maintain a general level of quality, but I'm willing to sacrifice that pretty easily in favor of other concerns. 11:34 MTDiscord I can't say that sfan5's responsibility level is a problem per se ... but at this point I'd be having some tense discussions about salary :-D 11:35 kilbith so either 1. give him more power or 2. urge HuguesRoss/rubenwardy/v-rob to distribute more approvals 11:35 kilbith that's the only ways I see 11:37 kilbith HuguesRoss since they have been a core-dev has given 1 or 2 approvals - something is wrong there 11:37 kilbith some people seems to take that role only for an honorific mention 11:41 MTDiscord If I were in charge, I might consider distributing some specific trust roles, like reviewer, where the person doesn't have permission to make changes or anything, but if they say they reviewed something and it'd good, then that officially counts for something, like as an approval, or possibly a portion of one or something. 11:42 MTDiscord Instead of "two approvals" you could make the requirement "one core dev approval, and one approval by any trusted reviewer or higher" or something. 11:42 Zughy[m] I don't think that pressing them would do any good. If we want to talk about people who went MIA, those are Pyrollo and Hecktest 11:43 Zughy[m] but at least the latter warned the staff 11:43 kilbith pyrollo doesn't have the time anymore - I've got him on the phone one week ago 11:43 MTDiscord This is a volunteer project, so if you can't work with people's schedules then you're not going to have a lot of people involved. 11:44 kilbith anyway enough talking 11:44 Zughy[m] people's schedules shouldn't be "I disappear for two years and bb" though 11:45 MTDiscord I have time sometimes, and I don't have time other times. I could be a core dev, but only actively for like a month here or there, and on hiatus for a few months here and there between. 11:45 Zughy[m] TurkeyMcmAc core dev when? 11:45 MTDiscord This is why I'm saying that we should consider non-all-or-nothing roles. 11:45 Zughy[m] *McMac 11:55 sfan5 there's a lot of stuff we can (should) document but as it is now you pretty much have to be a coredev (including experience writing code) to properly review many changes 11:56 sfan5 this is only a problem if there's no requirement for at least one coredev to be involved 12:03 nrz it's the problem with free software without company, devel is slower, just accept it and it's fine 12:07 MTDiscord The fact that dev is slower is inevitable, but we shouldn't just accept it being arbitrarily slower, we should find out how much of that is within our control and mitigate it as much as possible. 12:08 MTDiscord Slowness isn't 100% of the problem either. Not all dev work is equally important, and if we can steer more energy toward issues that are holding us back more strongly, instead of smaller annoyances, we can get better faster that way too. 13:09 kilbith question, we can't use `std::for_each` in MT correct? 13:10 kilbith guiCamera.cpp:36:14: error: ‘for_each’ is not a member of ‘std’ 13:13 sfan5 cppreference sas it exists in c++14 (or 11), did you include the right header? 13:14 kilbith https://en.cppreference.com/w/cpp/algorithm/for_each 13:14 kilbith looks like c++17 to me 13:18 nrz yep it's C++17 13:19 nrz what type of iteration are you doing ? because standard for with iterator cover many cases 13:19 kilbith I'm converting vectors 13:19 kilbith well no biggie 13:53 paradust pretty sure it's C++11. But what good is it? The usual iteration pattern is much more readable. 13:53 nrz it's not std::for_each but C++11 for if it's std::container should just work 15:26 Pexin I hope issue 12345 will be something about passwords 15:26 Pexin (sorry, chatter) 15:51 kilbith https://www.youtube.com/shorts/r8_R4c0DXmA 18:02 Zughy[m] Yes Pexin #12345 18:02 ShadowBot https://github.com/minetest/minetest/issues/12345 -- Ladies and gentlemen, this is mambo n°5 18:03 Pexin Zughy[m]: I saw. Am disappoint. 18:03 Pexin stand by 18:09 Pexin dang it warr beating me to it 18:20 MTDiscord ninja'd in a github issue thread, hate to see it 18:22 Pexin it's because I'm on my slow computer right now 19:05 MTDiscord Ironic that it was SmallJoker who didn't appreciate the joke. 19:40 sfan5 maybe we can merge some PRs today 19:40 sfan5 and I'm not thinking of the one that adds a single comma 19:44 Zughy[m] well, that's easy peasy 19:44 Zughy[m] I've changed the spawn_by documentation by the way if you want to go with that 19:47 sfan5 I was thinking of something more substantial 19:52 celeron55 < erle> regarding reviews: again, “you can do reviews but it will not count for anything” is not very motivating. 19:53 celeron55 ^ there's no rule saying a core dev has to do the review themselves. they can trust a non core dev with a review and state literally that they think a PR is good as reviewed it 19:53 sfan5 rubenwardy: since when does mod.conf have `title`? neither devtest nor MTG make any use of it 19:54 rubenwardy since ContentDB was added in 5.0 I believe 19:54 rubenwardy maybe I can't remember 19:54 MTDiscord sfan5: Merge the one that adds a single comma and free up the spot on the PR list, please. 19:54 sfan5 wait mtg uses `description` 19:55 sfan5 but it uses it in a way that's more suited to `title` 19:55 rubenwardy description is the short_description, title is the humanreadable title 19:55 rubenwardy title is shown in lists, whereever you're referring to the mod where you would previously use its name 19:56 rubenwardy description is shown when content is selected, in a multi-line text area 19:56 rubenwardy title allowed 3darmor to be 3D Armor, and minetest_game to be Minetest Game 19:58 erle celeron55 well, then feel free to point me to PRs where you don't have the time to read the code or try it out, but would indeed trust my judgement (which i would leave in form of a written review). that, of course goes for everyone else too. 19:58 erle (of course you would decide how good i judge it when you read it) 19:59 Zughy[m] dual wielding ? 20:00 erle Zughy[m] bUt WhaT iF yOu WaNt MoRe ThAn TwO HaNdS xD 20:00 Zughy[m] or the one by Wuzzy with one approval from 2021 20:00 Zughy[m] #11431 20:00 ShadowBot Zughy[m]: Error: That URL raised 20:00 erle cool cool 20:00 rubenwardy I think the idea of using a HUD element for hands is to allow more control, not to support more than two hands 20:01 erle #11431 20:01 ShadowBot erle: Error: That URL raised 20:01 erle okay, i guess it was not a fluke 20:02 MTDiscord being able to move the wield mesh to the center could be pretty interesting 20:02 erle quake style 20:03 MTDiscord indeed 20:03 erle Jordach would have a literal field day with that 20:03 MTDiscord if we're sticking with the corners, I'd sorta like to see quad-wielding for like a mech battle kind of game or something. 20:03 erle https://github.com/minetest/minetest/pull/11431 20:04 erle > Df458 added the One approval label Mar 15, 2022 20:04 MTDiscord If we could do first-person attachments that are NOT displayed to other players, you could probably do a lot of wield mesh stuff though, and much of the infrastructure is there. 20:04 erle you can already do that 20:05 erle i mean, send them differend dynamic textures hehe 20:05 erle different 20:05 MTDiscord oh wow, that's a nasty hack but intriguing... 20:05 MTDiscord granted, when you're using a "wielditem" visual type I don't think it'd work 20:06 erle well, i just came up with that so it totally might not 22:07 MTDiscord This has been thought of many times. But in my mind its impractical. Maybe someone will prove me wrong; id like that 23:08 erle MisterE[m] well, in my opinion you could make a secondhand mod right now 23:08 erle the thing is, it would look shitty in third person 23:08 erle and have zero functionality