Time Nick Message 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 03:14 rubenwardy https://twitter.com/github/status/1407731478096756739?s=19 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 17:41 MTDiscord 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. 18:30 celeron55 i think all features not marked as experimental, broken, deprecated or obsolete should be documented 18:33 MTDiscord 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 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 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 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 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 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 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 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 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 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 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 MTDiscord 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 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 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 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 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 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 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 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 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 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 more positive note, i'm now able to back support every Intel Mac 19:29 MTDiscord cmake reports it can build only up to OSX 10.9 which is "recent" enough 20:27 pgimeno reminder, after I was bitten by lack of text output recently: https://codeberg.org/pgimeno/minetest/pulls/1 20:27 MTDiscord Oh, was the text version removed? I thought it did both... 20:29 MTDiscord 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 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