Minetest logo

IRC log for #minetest-dev, 2021-06-24

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:01 Alias joined #minetest-dev
00:14 entuland corals have wildly varying appearances, where I live these are the most iconic ones: https://www.itinari.com/alghero-the-city-of-the-red-coral-0hf3
00:18 kilbith joined #minetest-dev
00:37 kilbith joined #minetest-dev
03:14 rubenwardy https://twitter.com/github/status/1407731478096756739?s=19
05:00 v-rob joined #minetest-dev
06:24 v-rob joined #minetest-dev
07:30 queria joined #minetest-dev
07:34 specing_ joined #minetest-dev
07:57 celeron55 sfan5: ah underwater stuff
08:00 celeron55 i feel like almost all wall-growing plants would need a texture plane parallel to the wall also
08:01 celeron55 because they usually aren't very high
08:01 celeron55 i mean, don't grow very sideways-tall from the wall
08:03 celeron55 and, for anything not underwater my problem with the 45° remains
08:05 celeron55 for reference https://github.com/minetest/minetest/pull/11379/ https://github.com/minetest/minetest/pull/11312
09:07 queria^clone joined #minetest-dev
09:09 entuland joined #minetest-dev
09:29 YuGiOhJCJ joined #minetest-dev
09:30 tekakutli joined #minetest-dev
09:37 calcul0n joined #minetest-dev
10:07 tekakutli left #minetest-dev
10:27 calcul0n_ joined #minetest-dev
11:29 Wuzzy joined #minetest-dev
11:42 queria joined #minetest-dev
11:47 appguru joined #minetest-dev
13:47 \c joined #minetest-dev
15:08 Fixer joined #minetest-dev
15:11 entuland joined #minetest-dev
15:36 VanessaE joined #minetest-dev
15:37 VanessaE joined #minetest-dev
15:37 bigfoot547 joined #minetest-dev
15:38 Krock joined #minetest-dev
15:40 cheapie joined #minetest-dev
15:41 Extex joined #minetest-dev
15:50 hecks joined #minetest-dev
16:26 wsor4035 joined #minetest-dev
16:44 Lone_Wolf joined #minetest-dev
17:41 MTDiscord <Techy5> Is there any reason not to document horizontal/vertical merge bits for glasslikeframed nodes? If not, I could probably open a PR, it seems like a trivial fix.
17:51 hecks joined #minetest-dev
18:14 Extex joined #minetest-dev
18:30 celeron55 i think all features not marked as experimental, broken, deprecated or obsolete should be documented
18:33 MTDiscord <Warr1024> If anything is undocumented then I would bet it's at least like 95% due to lack of available time/energy rather than intent.
18:37 celeron55 i'm trying to figure out if we have succesfully documented the formal process of accepting non-roadmapped PRs or not
18:40 celeron55 so, this https://github.com/minetest/minetest/blob/master/.github/CONTRIBUTING.md says "Any Pull Request that isn't a bug fix and isn't covered by the roadmap will be closed within a week unless it receives a concept approval from a Core Developer. For this reason, it is recommended that you open an issue for any such pull requests before doing the work, to avoid disappointment."
18:41 MTDiscord <Jordach> making it harder for people to contribute worsens the problem where we already have minimal outside contributors
18:42 celeron55 there's no mention at all anywhere about the fact that if a core dev concept approves something, they themselves have primary responsibility about the PR
18:42 MTDiscord <Warr1024> the need for concept approval isn't really something that would go away just because it's not documented as such; I mean, if nobody approves of the concept it's not gonna get merged anyway, so you'd have just wasted the effort.  It seems sort of obvious on that level anyway.
18:42 celeron55 Jordach: this is about making the process predictable; it being unpredictable has always been the primary problem
18:43 celeron55 anyway i'm looking at this from core dev's perspective
18:43 hecks Also, what if said core dev is wrong in their appraisal of the PR?
18:43 celeron55 what does a core dev do
18:43 MTDiscord <Warr1024> A core dev approving something doesn't necessarily make them responsible for it from a policy standpoint, but anyone whose name is attached to it is going to be associated from a public perception standpoint.
18:43 hecks what do the others do in that situation
18:44 hecks let's say it's a feature that isn't harmful per se but very bloaty like uhh
18:44 celeron55 hecks: they're only wrong if some other core dev vetos it or they can find no other core dev to approve it, i.e. they should check the situation regarding to those beforehand
18:44 Krock well approving should at least kind of feel you guilty for introducing a bug (in case), and to fix it.
18:44 MTDiscord <Warr1024> The way I understood the policy, I was actually surprised to even see a ">= 2 approvals" tag in github at all.  I assumed that the canonical way to add a second approval to the project was to make a comment to that effect ... and then immediately proceed with the merge.
18:45 celeron55 sometimes if two coredevs approve something very fast it's left for some time in case someone else wants to check or test it
18:45 MTDiscord <Warr1024> Ultimately someone on the core team (or some set of someones) must be responsible for each thing and those not involved in the conversation should bear less responsibility for a decision than those who made it.  But there should also be a limit to the level of punishment someone should have to bear.
18:45 celeron55 to avoid unnecessary problems in master
18:46 hecks alright then, in case of very stupid ideas it's a veto
18:46 MTDiscord <Warr1024> One thing I don't really know is what happens if core devs disagree on an item.  I sort of assumed that a conversation would happen and the team would try to arrive at a consensus, and not act either way until a consensus was found.
18:47 MTDiscord <Warr1024> Alternatively, there could be a voting sort of thing, i.e. there needs to be 2 more approvals than disapprovals or something ... but the consensus thing seems like the ideal, if not from a process efficiency standpoint, at least in terms of how the MT dev team wants to deal with its users.
18:48 rubenwardy Approval != Concept approval
18:48 MTDiscord <Warr1024> i.e. "I wasn't involved in that decision but I can look into it for you" is alright but "don't look at me, I was against it to begin with" doesn't seem quite right...
18:49 sfan5 [for PR approvals] I don't know if it's formalized but I always went by "two coredevs have to agree on it and concerns of disagreeing devs have to be addressed"
18:49 celeron55 rubenwardy: that's true - basically you can concept approve a PR before the implementation is satisfactory, and then ask for changes before you approve it or expect others to approve it
18:50 MTDiscord <Warr1024> Is there a specific separate process for concept approval?  I figured that proceeding with the PR was always sort of "at your own risk" for contributors so the degree of concept approval they would need from the core team just depended on their own risk tolerance...
18:50 rubenwardy Yeah exactly
18:50 celeron55 or you can concept approve and straight-up approve it instantly and then wait for someone else to also approve it
18:50 sfan5 regarding CONTRIBUTING.md if anyone edits it soon plese throw away the entire "Important note about automated GitHub checks"
18:50 rubenwardy Concept approval can be done without reading any code, just the description and the attached issue
18:50 sfan5 +a
18:51 MTDiscord <Warr1024> Are we just talking about formalizing a process for rejecting PRs instead of letting them accumulate indefinitely even though they are obviously going nowhere?  Or is this part of a different problem?
18:51 celeron55 i think this process should be written down from a core dev's standpoint in such a way that there's no room for interpretation, so that even a new core dev will feel confident doing it
18:51 rubenwardy Concept approval is done by adding the label "Supported by core dev"
18:52 v-rob joined #minetest-dev
18:52 MTDiscord <Warr1024> That seems pretty fair to me
18:52 celeron55 we're talking about a process that already was formalized but not properly written down, about PRs overally including the rejection of them
18:53 rubenwardy Might be worth pulling the core dev rules from dev wiki to a repo or doc/
18:53 MTDiscord <Warr1024> It wouldn't be bad to have guidance from a contributor's perspective though to warn them that it may not be a bad idea to wait for the dust to settle before investing time, and that just because something gets a concept approval doesn't mean it might not evolve over a little more time...?
18:53 hecks How does something like #9717 fit into this?
18:53 ShadowBot https://github.com/minetest/minetest/issues/9717 -- Extended motion mechanics API for LuaEntitySAOs by sorcerykid
18:53 hecks Technically harmless, but concept wise it's flawed
18:54 MTDiscord <Warr1024> Hmm, okay, I sort of assumed that I got the gist of the process; I'll be curious to see what's different then...
18:54 Krock well it does not fit, hence stalling
18:54 sfan5 if it's flawed you'd have devs rejecting it or requesting changes
18:55 celeron55 hecks: i think it's almos the opposite: the concept is fine, but this approach will definitely add technical debt
18:56 celeron55 almost*
18:56 hecks I mean, this PR attempts to tackle a bunch of mutually unrelated problems with band-aid features
18:56 rubenwardy Yeah I agree, I don't like the technical approach
18:56 hecks a real problem would be something like CAO traffic being too fat, or the lack of rigidbody physics features, or a proper transform API
18:56 MTDiscord <Jordach> i can feel the network bloat just by looking at it
18:57 celeron55 well the callbacks are not really on point, that's for usre
18:57 hecks so this is my example of a PR that ought to not get a "concept approval"
18:57 hecks also the ID parameters are weird because they're not true object GUIDs, we don't have those
18:57 hecks SAO ids are ephemeral, right?
18:58 celeron55 yes, they exist only for telling the clients which is which, while they're active
18:58 MTDiscord <Warr1024> I mean, there are a lot of different layers to ultimate "approval".  The core team needs to agree with the identification and assessment of the problem, the concept behind the approach to the solution, that the implementation actually works, that it fits the guidelines, is maintainable, and the trade-offs are acceptable...
18:59 hecks maybe it would be a good idea to tell contributors to avoid bundle PRs such as this and do one thing at a time
18:59 hecks if that isn't written somewhere already
18:59 celeron55 yeah, but most of the layers are actually only recommendations, the only rule is the "two devs approve if no dev vetoes" rule
19:00 hecks of course a veto should be justified and in good faith
19:01 sfan5 I don't think that veto thing is written down anywhere
19:02 sfan5 " Can vote for and against merging pull requests (Two for-votes are required for code to be mergeable upstream.) "
19:02 sfan5 depends on how pedantic you are..
19:02 MTDiscord <Warr1024> As a new core dev it DOES seem obvious to me though that vetoes should be a thing...
19:02 celeron55 well... it's obvious the against vote has to mean something
19:03 MTDiscord <Warr1024> I would hope that before someone does a merge they would review the comment thread on the PR and make sure there are no unresolved disputes, at least among the core team...
19:03 MTDiscord <Warr1024> If there were tags for it then that might streamline things a lot.
19:04 hecks unresolved dispute is a better way to say it unless a concept is just unsalvageable
19:04 hecks there's often a way out without tossing out the whole PR
19:05 hecks like in the case of 9717 again the solution is to cherrypick the good apis and resubmit as individual features
19:06 celeron55 i already forgot about 9717 completely but if someone has looked at it recently and thought it has a specific good api, maybe it's worth commenting so
19:09 celeron55 i guess, overall, we'll conclude: just do whatever, it'll be fine, the base rule makes sure at least someone else also looked at it anyway
19:11 celeron55 i'm the type of person who can design a process just fine, but once it's taken more than an hour or would have to be written down, i lose interest
19:12 celeron55 https://github.com/minetest/minetest/pull/11379
19:12 MTDiscord <Warr1024> A system of tags for disputes would be nice at least because the idea of digging through all the comments on 9717 to make sure somebody didn't raise a legit concern that never got resolved and got buried seems daunting.
19:12 celeron55 anyway i'm now concept approving and straight-up approving this
19:13 rubenwardy The tag for this is "Controversial"
19:13 MTDiscord <Warr1024> Ah, okay, I can keep an eye out for those.
19:14 sfan5 do you think we should have both wallmounted and facedir then?
19:14 sfan5 for plantlike
19:15 celeron55 well, actually i don't really care which
19:17 celeron55 well Wuzzy says here what i think i guess  https://github.com/minetest/minetest/pull/11312#issuecomment-866941067
19:18 celeron55 if the use case is plants, wallmounted is fast and easy
19:18 hecks consider the following; plantlike nodes don't really care about yaw
19:18 hecks facedir doesn't make too much sense for them
19:20 sfan5 wallmounted it is then
19:20 Wuzzy good =)
19:24 MTDiscord <Jordach> more positive note, i'm now able to back support every Intel Mac
19:29 MTDiscord <Jordach> cmake reports it can build only up to OSX 10.9 which is "recent" enough
19:35 specing_ joined #minetest-dev
20:19 queria joined #minetest-dev
20:27 pgimeno reminder, after I was bitten by lack of text output recently: https://codeberg.org/pgimeno/minetest/pulls/1
20:27 MTDiscord <Warr1024> Oh, was the text version removed?  I thought it did both...
20:29 MTDiscord <Warr1024> I run a mod that exposes an admin console as a unix-domain socket for admin stuff over SSH without actually launching the client.  Mostly that means script access, but I do sometimes use it interactively and it'd be really nice if everything still worked in chat-text.
20:30 MTDiscord <Warr1024> Oh interesting, it looks like 8869 uses name == "" as a heuristic to detect the built-in terminal user, but that doesn't work for using a socket/mux terminal mod I guess.
20:33 pgimeno I think there was some discussion on that when I first presented the PR
20:34 pgimeno note also it adds translatable strings
20:41 Thomas-S joined #minetest-dev
20:41 Thomas-S joined #minetest-dev
20:49 Lone_Wolf joined #minetest-dev
22:21 ShadowBot joined #minetest-dev
22:21 ShadowNinja joined #minetest-dev
22:21 Pexin joined #minetest-dev
22:21 book` joined #minetest-dev
22:21 basxto joined #minetest-dev
22:21 m42uko joined #minetest-dev
22:21 Thomas-S joined #minetest-dev
22:21 v-rob joined #minetest-dev
22:21 VanessaE joined #minetest-dev
22:21 entuland joined #minetest-dev
22:21 Fixer joined #minetest-dev
22:21 Sokomine joined #minetest-dev
22:21 Jordach joined #minetest-dev
22:21 nrz joined #minetest-dev
22:21 MTDiscord joined #minetest-dev
22:21 Evergreen joined #minetest-dev
22:21 ivanbu joined #minetest-dev
22:22 queria joined #minetest-dev
22:22 Extex joined #minetest-dev
22:22 Krock joined #minetest-dev
22:22 Wuzzy joined #minetest-dev
22:22 calcul0n_ joined #minetest-dev
22:22 pgimeno joined #minetest-dev
22:22 pmp-p joined #minetest-dev
22:22 cheapie joined #minetest-dev
22:22 | joined #minetest-dev
22:22 Alias joined #minetest-dev
22:22 rubenwardy joined #minetest-dev
22:22 BuckarooBanzai joined #minetest-dev
22:22 clavi joined #minetest-dev
22:22 wsor4035 joined #minetest-dev
22:22 olliy joined #minetest-dev
22:23 jonadab joined #minetest-dev
22:23 nore joined #minetest-dev
22:23 dzho joined #minetest-dev
22:23 sfan5 joined #minetest-dev
22:23 ssieb joined #minetest-dev
22:23 beanzilla joined #minetest-dev
22:23 freshreplicant[m joined #minetest-dev
22:23 Shara joined #minetest-dev
22:24 luk3yx joined #minetest-dev
22:25 Noisytoot joined #minetest-dev
22:25 Extex joined #minetest-dev
22:25 nrz joined #minetest-dev
22:32 nrz joined #minetest-dev
22:33 specing joined #minetest-dev
22:36 Alias joined #minetest-dev
22:37 T4im joined #minetest-dev
22:53 tekakutli joined #minetest-dev
22:54 YuGiOhJCJ joined #minetest-dev
23:59 AliasAlreadyTake joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext