| Time |
Nick |
Message |
| 00:05 |
|
erle joined #minetest-dev |
| 00:12 |
|
kilbith joined #minetest-dev |
| 01:04 |
|
proller joined #minetest-dev |
| 01:28 |
|
erle joined #minetest-dev |
| 01:49 |
MTDiscord |
<exe_virus> I can be benevolent, but absolutely don't have the time or the git history to back up my credentials publically |
| 01:49 |
MTDiscord |
<exe_virus> maybe in a couple years/decade |
| 02:15 |
MTDiscord |
<ZweiKamel> What if Rubenwardy was the trusty c55 sidekick? |
| 02:28 |
|
queria^clone joined #minetest-dev |
| 02:33 |
|
queria^clone joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:22 |
|
behalebabo joined #minetest-dev |
| 05:04 |
erle |
<kilbith> 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 |
| 05:50 |
|
calcul0n joined #minetest-dev |
| 05:59 |
|
nrz joined #minetest-dev |
| 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:31 |
|
Fixer joined #minetest-dev |
| 09:33 |
|
queria joined #minetest-dev |
| 09:38 |
|
appguru joined #minetest-dev |
| 09:45 |
|
HuguesRoss0 joined #minetest-dev |
| 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 |
<Warr1024> 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:50 |
|
kilbith joined #minetest-dev |
| 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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. |
| 12:46 |
|
erle joined #minetest-dev |
| 13:09 |
|
kilbith joined #minetest-dev |
| 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:43 |
|
proller joined #minetest-dev |
| 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:27 |
|
kilbith joined #minetest-dev |
| 15:51 |
kilbith |
https://www.youtube.com/shorts/r8_R4c0DXmA |
| 17:20 |
|
Taoki joined #minetest-dev |
| 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 |
<ROllerozxa> 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 |
| 18:57 |
|
Warr1024 joined #minetest-dev |
| 19:05 |
MTDiscord |
<Warr1024> Ironic that it was SmallJoker who didn't appreciate the joke. |
| 19:09 |
|
x2048 joined #minetest-dev |
| 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 <whoever> 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 |
<luatic> 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:57 |
|
appguru joined #minetest-dev |
| 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 <Connection timed out.> |
| 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 <Connection timed out.> |
| 20:01 |
erle |
okay, i guess it was not a fluke |
| 20:02 |
MTDiscord |
<Warr1024> being able to move the wield mesh to the center could be pretty interesting |
| 20:02 |
erle |
quake style |
| 20:03 |
MTDiscord |
<Warr1024> indeed |
| 20:03 |
erle |
Jordach would have a literal field day with that |
| 20:03 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> oh wow, that's a nasty hack but intriguing... |
| 20:05 |
MTDiscord |
<Warr1024> 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 |
| 20:28 |
|
proller joined #minetest-dev |
| 21:26 |
|
Thomas-S joined #minetest-dev |
| 22:07 |
MTDiscord |
<MisterE> This has been thought of many times. But in my mind its impractical. Maybe someone will prove me wrong; id like that |
| 22:36 |
|
panwolfram joined #minetest-dev |
| 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 |
| 23:13 |
|
Alias joined #minetest-dev |
| 23:41 |
|
AliasAlreadyTake joined #minetest-dev |
