| 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 |
