| Time |
Nick |
Message |
| 01:36 |
MTDiscord |
<exe_virus> idk, I have NVME m.2 drives at work and the switch to RAM was a nice speedup for our compilations |
| 02:43 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 05:12 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:30 |
|
SFENCE joined #minetest-dev |
| 06:03 |
|
SFENCE joined #minetest-dev |
| 06:11 |
|
SFENCE joined #minetest-dev |
| 06:51 |
|
cranez joined #minetest-dev |
| 07:02 |
|
SFENCE joined #minetest-dev |
| 07:09 |
|
SFENCE joined #minetest-dev |
| 07:12 |
|
SFENCE joined #minetest-dev |
| 07:17 |
|
SFENCE joined #minetest-dev |
| 11:46 |
|
Lupercus joined #minetest-dev |
| 11:47 |
[MatrxMT] |
<Zughy> PRs are still on the rise, that's not good, although I do realise people have more free time during the summer. If we could focus on approving more rather than opening new PRs it'd be great |
| 11:48 |
sfan5 |
>I do realise people have more free time during the summer |
| 11:48 |
sfan5 |
you mean less? |
| 12:08 |
[MatrxMT] |
<Zughy> sfan5: no, more. Like people who maybe would like to contribute but they're busy with work/studying, they can actually do it in summer (and around the end of the year) |
| 12:09 |
[MatrxMT] |
<Zughy> People as in external contributors |
| 12:12 |
[MatrxMT] |
<Zughy> Pulse data is of no help but my perception is that we've seen more PRs than usual in these weeks |
| 12:49 |
MTDiscord |
<josiah_wi> I had a small unit test PR that was already reviewed and merged. I had a break between internship and classes and had time to contribute, like Zughy said. |
| 12:51 |
[MatrxMT] |
<Zughy> Knowing these things is helpful for the future in my opinion, as it allows us to know what to expect more or less according to the time of the year. For instance, I don't remember a significant increase right after FOSDEM |
| 12:52 |
MTDiscord |
<rudzik8> don't forget summer is the vacation season there's nothing surprising in people wanting to lay on sunny beaches instead of sitting behind a computer screen |
| 12:52 |
MTDiscord |
<rudzik8> and when that season comes to an end, everybody's like "shit I got to lock in" |
| 12:53 |
[MatrxMT] |
<Zughy> So if "I" know that e.g. August and December are in general pretty hectic, I won't start new ideas during those periods as it might bring to overwhelming me and/or the the rest of the staff |
| 12:56 |
MTDiscord |
<rudzik8> BTW what is this channel bridged to on Matrix? #minetest-dev:libera.chat doesn't seem to update at all, nor does it have any messages in it |
| 13:06 |
|
hwpplayer1 joined #minetest-dev |
| 13:13 |
MTDiscord |
<rudzik8> anyways. is this another non-personal-but-pretty-specifically-personal jab? should I apologize for making a PR at the "wrong" month? |
| 13:14 |
MTDiscord |
<rudzik8> I'm not saying your points are invalid, it's just that, again, you could've addressed me directly |
| 13:20 |
MTDiscord |
<rudzik8> ...in case it relates to me, of course |
| 13:21 |
celeron55 |
i'd say... all of it is par for the course: zughy stressing out on the number of PRs, everyone being busy at every time of the year, and contributors being confused |
| 13:22 |
celeron55 |
(i don't mean it's very good, but it happens) |
| 13:37 |
[MatrxMT] |
<Zughy> rudzik8: what, no, I'm genuinely preoccupied for the status of the project. Can people stop thinking I'm an arsehole please? :/ |
| 13:37 |
MTDiscord |
<herowl> celeron55: Minetest has 115 open PRs and we in VoxeLibre have 113 open PRs |
| 13:38 |
MTDiscord |
<herowl> Tbh I'm not stressing over that in VL, and in my opinion engine may have well more PRs than a game made under it |
| 13:39 |
[MatrxMT] |
<Zughy> Yep but we were able to reach ~70PRs, which I think it's healthier |
| 13:40 |
MTDiscord |
<herowl> I was trying to keep PRs under 25, then under 50, then under 75, then I gave up and it is what it is |
| 13:40 |
MTDiscord |
<herowl> Wr have a lot of drafts for example, and it's OK |
| 13:40 |
MTDiscord |
<herowl> Btw rudzik8 wanted to close some of them and I refused. |
| 13:41 |
MTDiscord |
<herowl> We have* |
| 13:43 |
MTDiscord |
<herowl> Zughy: re "thinking you are arsehole": we genuinely think your reaction to my doc PR was way overreaction (suggesting to remove the behavior entirely) |
| 13:43 |
|
SFENCE joined #minetest-dev |
| 13:43 |
MTDiscord |
<herowl> So you should understand that our devs may be way too suspicious of whatever you say |
| 13:46 |
MTDiscord |
<luatic> In this case rudzik unnecessarily took a general observation - one that was even made before any of the drama in that issue unfolded - personally. See e.g. the mainmenu redesign issue, where Zughy deferred pinning it to avoid overwhelming the team. |
| 13:46 |
[MatrxMT] |
<Zughy> I think that my 3rd comment was too, I was nervous and I shouldn't have commented in that mental state, so I'm sorry for the tone. But I don't think that portraying me like that in general is fair |
| 13:47 |
MTDiscord |
<herowl> Now returning to the negative saturation thing, because that's what I came here for: it's not inversion, but it certainly is an interesting effect. I have posted some information on a non-bridged channel, and I'll post it again here: * it preserves Luma (perceived brightness) * it preserves saturation (expressed as chroma/Luma), so 1 and -1 is the same saturation * it alters hue either by exactly 180 degrees or by some seemingly random |
| 13:47 |
MTDiscord |
value |
| 13:48 |
MTDiscord |
<herowl> Looks generally like some form of "brightness preserving inversion", since normal inversion turns light colors into dark ones and vice versa |
| 13:48 |
MTDiscord |
<herowl> Quite interesting tbh |
| 13:49 |
MTDiscord |
<herowl> I still think it should be kept and documented, and I'd like to talk about how to word it here. |
| 13:50 |
MTDiscord |
<luatic> If this is to be documented, the only viable way is probably to just slam the formula there. |
| 13:51 |
MTDiscord |
<herowl> So just slam the formula and then describe the effects a bit? |
| 13:52 |
MTDiscord |
<luatic> Yes, that seems acceptable. |
| 13:53 |
[MatrxMT] |
<Zughy> herowl: on AES whenever we reach 50 issues we stop from introducing whatever new feature (except for "Waiting for upstream"). Not too much fun sometimes but everything is in order and whenever some big bug/crash pops up, we have all the time to focus on that without the pressure of the rest of the huge pile |
| 13:54 |
MTDiscord |
<herowl> We have over 900 issues on VL repo |
| 13:54 |
[MatrxMT] |
<Zughy> Ouchie |
| 13:54 |
MTDiscord |
<rudzik8> I understand this and won't try to escalate this, only explain myself I think Herowl had put this better than I could ever do. my previous interaction with Zughy on GitHub don't make this one any better if Zughy feels like they're portrayed wrongly, I'm sorry, but that's how some of your messages can come across. I don't actually think Zughy's an "arsehole" |
| 13:54 |
MTDiscord |
<herowl> Many of which probably could be closed by now... but yeah |
| 13:57 |
[MatrxMT] |
<Zughy> rudzik8: thank you for the clarification, I hope there's no bad blood between us, and actually thanks for your latest PR :) |
| 13:58 |
MTDiscord |
<rudzik8> Zughy: thanks for all the work you put into Minetest ❤️ |
| 13:59 |
celeron55 |
enterpreneurs use the term "positive problem". as annoying as it is, too many PRs is one of those |
| 14:00 |
celeron55 |
yes you can have policies with hard limits, but that would be a big change to how MT development is run |
| 14:03 |
|
Desour joined #minetest-dev |
| 14:03 |
|
SFENCE joined #minetest-dev |
| 14:06 |
MTDiscord |
<luatic> if we're entrepreneurs now we should start putting AI and crypto into Minetest 😄 |
| 14:07 |
MTDiscord |
<luatic> On a more serious note, I don't think hard limits are a good idea, because priorities need to be pretty dynamic. |
| 14:08 |
sfan5 |
priority: deliver the next release and have it be overall better than the previous one |
| 14:11 |
|
luatic joined #minetest-dev |
| 14:13 |
luatic |
Anyways sfan5, Desour: What's your status on the static gltf PR (#14557)? |
| 14:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/14557 -- Add static glTF support by JosiahWI |
| 14:13 |
luatic |
I interpret Desour's last comment as wanting to do a review? If so I'll wait for that to finish before I merge. |
| 14:14 |
Desour |
I just wanted to take a quick look (to see what changes in the minetest codebase), and found some small things. I didn't want to do a full review. so go ahead with the plans you had before I came :) |
| 14:22 |
luatic |
Desour: Great, thanks for letting me know. Guess I won't have to reschedule the merge party in *checks notes* 3 days. |
| 14:22 |
MTDiscord |
<josiah_wi> Haha, I was just checking the date, too. |
| 14:24 |
MTDiscord |
<rudzik8> Place the glTF loader on the ground then lie on your stomach with your arms at your sides. A merge party associate will arrive shortly to collect you for your merge party. |
| 14:34 |
sfan5 |
luatic: no status change. if I don't get to it, don't wait for me |
| 14:35 |
sfan5 |
only concern is conflicts with #15076 |
| 14:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/15076 -- [no squash] Ability to handle vertex and index VBOs separately by sfan5 |
| 14:35 |
sfan5 |
it might be easier for you to rebase yours than me mine |
| 14:46 |
luatic |
hmm, i'd expect there to not be significant conflicts either way. the impact should be comparable to the changes needed in the other loaders. |
| 14:48 |
sfan5 |
if you squash yours that one conflict vs potential 5+ conflicts, I was thinking |
| 14:51 |
luatic |
sfan5: i was planning to squash it anyways, the history isn't terribly useful at this point |
| 14:52 |
MTDiscord |
<warr1024> I think people reacted badly to the "negative saturation" issue because they felt like they were trying to make an improvement to the engine (improve documentation) and got "burned" by it when it looked like they were going to lose access to a feature because of it. |
| 14:52 |
MTDiscord |
<warr1024> I've gotta admit that that I've noticed that kind of chilling effect myself. There have been times when I've been unsure whether it's a good idea to file an issue because there was always a risk that the resolution of the issue would make the engine worse for my use-case. |
| 14:54 |
MTDiscord |
<warr1024> There was clearly a disconnect there because gamedevs found a weird funky psychadelic effect and didn't really care about whether the underlying math behind it was "correct", but the engine devs seemed to care about having only correct, well-specified, and planned functionality. |
| 14:55 |
MTDiscord |
<warr1024> A lot of the time we're trying to make games fun and interesting, not correct or rational. That leads to conflicts like this. |
| 14:56 |
luatic |
to make my stance clear, i am not in favor of taking this feature away. |
| 14:57 |
luatic |
i see either the option of keeping it (which leaves a bit of a sour taste in my mouth but i can live with it) or deprecating it in favor of a "proper way" to achieve a similar effect in a more well-behaved manner. |
| 14:58 |
MTDiscord |
<warr1024> Unfortunately that's not entirely in your control, and as gamedevs we've seen discussion around an issue evolve like -> we shouldn't support this hack, we should do it properly -> split "remove the hack" and "do it properly" into separate issues -> "remove the hack" is easy and gets done, "do it properly" turns out to be complicated and stagnates. It's a natural risk in issue management and it happens in our own backlogs too. |
| 15:01 |
luatic |
warr1024: i mean it in an atomic way. as in, i'd not accept a PR that just does one without the other. |
| 15:01 |
MTDiscord |
<warr1024> You could probably mitigate the chilling effect on issue reporting this causes by providing some kind of guarantee that "remove the hack" will always be a dependency of "add the proper fix" first, so at least we can be sure we will never lose ground. Having to add version compat hacks to transition from a deprecated method to a supported one is a mere annoyance, but a gap in functionality is a different story entirely. |
| 15:01 |
sfan5 |
has this actually happened in the past? |
| 15:02 |
MTDiscord |
<warr1024> Like I said, it's not only the minetest engine where people learn this :-) |
| 15:04 |
MTDiscord |
<warr1024> If you're asking for a specific case of it, I don't recall one, but it's been quite a few years and I forget a lot of stuff. I'm pretty sure that I'm not just projecting this from other projects, and I've seen it in MTE before. I'm not sure if it every eventually worked out this way (very often neither adding the proper fix NOR removing the hack ends up happening) but the "threat" of it is enough to make people regret they reported |
| 15:04 |
MTDiscord |
something. |
| 15:04 |
MTDiscord |
<warr1024> People who reported negative saturation are already surely regretting having gotten involved, and that issue is nowhere near resolved. |
| 15:08 |
MTDiscord |
<warr1024> The irony is that MTE has actually historically taken a very strong pro-backwards-compat stance to the point where it makes forward progress hard because of old features that are a pain to deprecate gracefully. The problem arises because people aren't sure that "backward compat" includes old bugs, even if they turn out to be useful. |
| 15:08 |
MTDiscord |
<warr1024> Undocumented features are a calculated risk we often have to take. Making a game that uses ONLY completely documented APIs ... actually sounds like kind of a fun challenge someday, or maybe some kind of penalty game 😆 |
| 15:10 |
sfan5 |
documented APIs is not that hard depending on what you're doing |
| 15:10 |
sfan5 |
but you often rely on internal behaviour despite that |
| 16:05 |
|
SFENCE joined #minetest-dev |
| 16:16 |
[MatrxMT] |
<Zughy> RE PRs: the goal here is not to have policies with hard limits, just to avoid the situation to become unmanageable |
| 16:19 |
[MatrxMT] |
<Zughy> Right now on the table we have: 5.9.1, 5.10, name change, 100+ PRs and (for some of us) the hope to go to FOSDEM 2025. That's already too much in my opinion |
| 16:21 |
|
Desour joined #minetest-dev |
| 16:23 |
[MatrxMT] |
<Zughy> And if more things keep coming without others being addressed, the result is that something will be forgotten because it'll come a time where people will be busy with life and it won't be able to tackle all these things - or they'll do it poorly |
| 16:26 |
[MatrxMT] |
<Zughy> To be clear: with 5.10 I meant the experiment of releasing more often. Which, being new, it'll need time for us adapt and draw conclusions |
| 16:26 |
[MatrxMT] |
<Zughy> *to adapt |
| 16:27 |
MTDiscord |
<wsor4035> did anyone every agree in 5.10 what the experiment was going to be? other than the hope of releasing faster? i know there was some ideas put out |
| 16:30 |
[MatrxMT] |
<Zughy> Not in the details as far as I remember, just release every 3 months |
| 16:31 |
MTDiscord |
<warr1024> I like the idea of a regular release schedule that's independent of whether thare are significant changes or not |
| 16:32 |
[MatrxMT] |
<Zughy> Right now it's the "wishlist" time, where you see different kind of issues and PRs added in there. I guess that one month prior we'll keep removing things not doable in time from there, yet this might result in contributors being annoyed. We'll see |
| 16:36 |
|
fluxionary joined #minetest-dev |
| 18:21 |
|
Evergreen3 joined #minetest-dev |
| 18:24 |
|
red-001 joined #minetest-dev |
| 18:28 |
|
red-001 joined #minetest-dev |
| 19:44 |
|
SFENCE joined #minetest-dev |
| 20:47 |
|
SFENCE joined #minetest-dev |
| 21:04 |
|
SFENCE joined #minetest-dev |
| 21:38 |
|
SFENCE joined #minetest-dev |
| 21:59 |
|
SFENCE joined #minetest-dev |
| 22:21 |
[MatrxMT] |
<AncientMariner> Zughy. I will apologise for going heavy on you. I will also apologise for making assumptions about your motives. I will also thank you for the work you put in on the high priority bugs, it's much needed |
| 22:21 |
|
Lupercus joined #minetest-dev |
| 22:21 |
[MatrxMT] |
<AncientMariner> I have to be honest though, I get frustrated with your approach at times, and I do hope things can improve |
| 22:23 |
[MatrxMT] |
<AncientMariner> what works in AES may not work in a larger project. i don't think you can put arbitrary numbers on prs and issues and enforce them. anything over that number it is like giving a middle finger to them |
| 22:23 |
[MatrxMT] |
<AncientMariner> the desire for tidyness and organisation comes at a cost of openness |
| 22:23 |
[MatrxMT] |
<AncientMariner> godot have 2.8k issues https://github.com/godotengine/godot/pulls |
| 22:23 |
[MatrxMT] |
<AncientMariner> sorry, prs, and 5k issues |
| 22:24 |
[MatrxMT] |
<AncientMariner> obviously they're well funded, but they're also well organised and progressing well. they're also scaling up effectively |
| 22:25 |
[MatrxMT] |
<AncientMariner> if there are too many issues, and some are irrelevent right now. mark them as low priority, and ensure people know how to use filters on github. even share some useful ones |
| 22:25 |
[MatrxMT] |
<AncientMariner> same with prs. if you go to prs and ignore all marked low priority, it's pretty clean |
| 22:26 |
[MatrxMT] |
<AncientMariner> a successful project isn't something with an empty issue tracker. it's full, as people raise the bugs. it also has a LOT of prs, because people are trying to help fix it |
| 22:27 |
[MatrxMT] |
<AncientMariner> tags such as "awaiting contributor" for example, means you can filter by most recently updated and see if anything needs moving off there, and you can get all prs, minus low priority or awaiting contributors. good filters keep things clean and easy for devs. good clear milestones also |
| 22:28 |
[MatrxMT] |
<AncientMariner> but if people care about mt, and raise stuff, and it's ignored. folk get frustrated. people do not get frustrated about stuff they do not care about. people do not always want to get there way. they just want to be listened to |
| 22:29 |
[MatrxMT] |
<AncientMariner> they just want some consideration that what they're raising isn't going to be thrown a no by default. it's exhausting having to justify something every time. it's easier to ask why first, than to say no and have to u-turn later |
| 22:29 |
[MatrxMT] |
<AncientMariner> if you default to no, the interactions you will have on the issue tracker will be a lot harder as the strategy is a frustrated other person by default |
| 22:32 |
[MatrxMT] |
<AncientMariner> the thing i realised, is you never get a clear issue tracker. you'll never be bug free. the moment you make things could, people raise somewhat unimportant stuff that is annoying. you close 10 high priority issues, and 20 low priorities appear. that's fine. you just focus on the criticals -> highs -> elevateds -> mediums |
| 22:32 |
[MatrxMT] |
<AncientMariner> and by the time you're on the mediums, your issue tracker is still pretty full, but you software is much better |
| 22:33 |
MTDiscord |
<greenxenith> Pretty sure most of us dont hold the opinion that "less prs is better" |
| 22:33 |
[MatrxMT] |
<AncientMariner> triaging issues is about prioritising, not removing |
| 22:33 |
|
SFENCE joined #minetest-dev |
| 22:34 |
[MatrxMT] |
<AncientMariner> in a hospital, they don't remove not dying immediately but still sick people, they just want to know who to deal with first |
| 22:34 |
[MatrxMT] |
<AncientMariner> green, maybe, but zughy is the active face of mt issues as a triager, and it's the policy of mt at the moment it seems |
| 22:35 |
[MatrxMT] |
<AncientMariner> but if priorities can get put on, and or areas of where it is (shaders, ui etc.), contributors can find what they need |
| 22:38 |
|
panwolfram joined #minetest-dev |
| 22:45 |
[MatrxMT] |
<AncientMariner> i will say warr made some excellent points earlier |
| 22:53 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:19 |
MTDiscord |
<corarona> not that i don't agree with this but they do remove "not hospital kind of sick" people pretty quickly :p |
| 23:20 |
MTDiscord |
<warr1024> I wouldn't say "fewer PRs is better" but "fewer PRs that are ahead of mine in line" definitely are. Work tends to get added to a queue in various places, as priorities are evaluated. However, when it's being pulled off the top of the queue at all, it's being pulled off at a certain maximum rate. |
| 23:21 |
MTDiscord |
<warr1024> The problem is that, the more items there are above any specific item in priority, the more likely it is that any new item in the future gets added above it. That means that unless the rate that items being added above is less than the rate they're being dequeued, then your item is moving BACKWARDS on the conveyor belt. |
| 23:21 |
MTDiscord |
<corarona> I think the actual point is the number of issues or PRs open, closed or processed says little about how much work got done or how well a project is doing |
| 23:21 |
MTDiscord |
<warr1024> We can hang onto items like that forever if we wish, but we need to be realistic about whether they're actually going to get worked on, and we can't be reevaluating their priority at every meeting. |
| 23:21 |
red-001 |
merging more PRs is how you get fewer PR realistically. |
| 23:21 |
red-001 |
PRs* |
| 23:22 |
red-001 |
merge or close |
| 23:22 |
MTDiscord |
<warr1024> Making decisions about PRs is how you get to fewer PRs. That decision could be merging, yes. But MTE for better or for worse has certain standards it wants to meet, and not every PR is going to meet those. |
| 23:23 |
MTDiscord |
<warr1024> Closing PRs without an explanation, or recourse, is a pretty lousy experience for the opener. The core team may need to just provide some kind of "so, your PR got rejected, here's what's next" guide or something that lets people down gently and gives them advice on how they might make another attempt at it next time. |
| 23:24 |
MTDiscord |
<warr1024> Resubmitting a rejected PR should be fine, but probably have some kind of rate limit, like you can only attempt it once per release, where we start doing releases every 3 months regularly. |
| 23:24 |
MTDiscord |
<corarona> in my experience it can be good to help PRs to meet standards as a way to get things done more quickly |
| 23:24 |
MTDiscord |
<warr1024> Right, and the core devs could really use more help with that. |
| 23:25 |
MTDiscord |
<warr1024> Not being a core dev means you can't make an authoritative decision about a PR, like voting to merge it, but it doesn't mean you can't give somebody advice, if you understand the standards well. |
| 23:26 |
[MatrxMT] |
<AncientMariner> do you need to reevaluate the priorities of everything at every meeting? if you have 10 high issues. 5 mediums, and 20 lows, you can ignore anything but the highs. of couse give facility for someone to appeal priority |
| 23:26 |
red-001 |
I'm not convinced endless debate on non-feature PRs is doing much to help with keeping code standards. If the change isn't *worse* than the existing implementation. |
| 23:26 |
red-001 |
features are difference of course |
| 23:27 |
MTDiscord |
<warr1024> If, say, we've got 50 PRs, and it's quite clear that there's no way 30 of them are going to get reviewed before the 5.10 deadline, then I think we should just close those 30, with each one getting a message saying "sorry, not planned for 5.10, if you still want this, please reopen when 5.11 dev starts" and possibly some advice about making it clearer WHY the thing should be considered higher priority next time around. |
| 23:27 |
MTDiscord |
<corarona> why |
| 23:27 |
MTDiscord |
<warr1024> AM: no, you don't have to reevaluate things that are already low priority, but if they're "stuck" in low priority then that's sort of like the trash can already. |
| 23:27 |
MTDiscord |
<corarona> who does it hurt that a pr is open? |
| 23:28 |
MTDiscord |
<greenxenith> Closing the prs seems pointless |
| 23:28 |
MTDiscord |
<warr1024> cora: two reasons. |
| 23:28 |
[MatrxMT] |
<AncientMariner> why close them? why not just not have them in themilestone? |
| 23:28 |
[MatrxMT] |
<AncientMariner> then you just click on the milestone and that's all you have to care about |
| 23:28 |
MTDiscord |
<warr1024> For one, it's more honest to tell people up front that their work is not going to get merged this cycle instead of just slapping a "well maybe" label on it when you already know it really doesn't have a chance. |
| 23:28 |
MTDiscord |
<luatic> AncientMariner: by your 2nd "them" you mean those PRs you want in the respective release (high priority ones), correct? |
| 23:28 |
[MatrxMT] |
<AncientMariner> closing if an author doesn't do anything in a few months is fair with adoption needed |
| 23:29 |
MTDiscord |
<corarona> well you can tell them without closing the pr |
| 23:29 |
MTDiscord |
<warr1024> the other reason is that it naturally filters out stuff that the authors themselves don't really care about, making it more likely that PRs whose authors DO resubmit next cycle get merged. |
| 23:29 |
MTDiscord |
<corarona> e.g. with the milestone thing as ancient proposed |
| 23:29 |
MTDiscord |
<warr1024> If literally closing the PR seriously causes a bunch of butthurt then we can just slap a "not closed :-)" label on it, it makes no difference to me. |
| 23:29 |
|
SFENCE joined #minetest-dev |
| 23:29 |
[MatrxMT] |
<AncientMariner> if someone raises a pr to fix something, just because it isn't in the delivery plan, doesn't mean it's not valid. if it's poor, say why and close, or give feedback on how to improve |
| 23:30 |
red-001 |
or could just merge more |
| 23:30 |
MTDiscord |
<greenxenith> Yeah, closing prs is the wrong function to use for "not this release" |
| 23:30 |
[MatrxMT] |
<AncientMariner> i would say if something hasn't been reviewed in 2 months, someone should try and get some eyes on it |
| 23:31 |
[MatrxMT] |
<AncientMariner> because after 2 months, that person stopped caring about it |
| 23:31 |
red-001 |
I mean there's no reason contributors shouldn't be asked to review other PRs and those reviews shouldn't count towards approval |
| 23:31 |
MTDiscord |
<warr1024> If you want to keep the compost pile in the same place as the stuff being worked on, that's fine too, I'm pretty sure GH supports that. It won't change the reality though that some things are just not moving forward. |
| 23:31 |
MTDiscord |
<greenxenith> Maybe the disconnect here is we disagree who as at fault for not moving forward |
| 23:31 |
MTDiscord |
<warr1024> "Get some eyes on it" is not going to happen if even a PR's OWN author has abandoned it. |
| 23:32 |
[MatrxMT] |
<AncientMariner> i do not understand a person who could be ignored for months about something they were enthusiastic about, then given feedback and jump in with the same energy |
| 23:32 |
MTDiscord |
<warr1024> If NO PRs are moving forward then that's the core team's fault. If SOME PRs are moving forward, then it's not. |
| 23:32 |
red-001 |
people do in fact have things to be doing |
| 23:32 |
MTDiscord |
<greenxenith> It depends entirely on the pr |
| 23:32 |
[MatrxMT] |
<AncientMariner> as i say, if they abandoned it for 2 months, close with needs adoption |
| 23:33 |
[MatrxMT] |
<AncientMariner> but often it isn't with the author |
| 23:33 |
[MatrxMT] |
<AncientMariner> i've seen 5 line prs closed for inactivity in 1 month |
| 23:33 |
MTDiscord |
<greenxenith> You can't say it is an entire groups fault for all slowness based on overall metrics |
| 23:33 |
[MatrxMT] |
<AncientMariner> i mean come on, probably easier just to review it and give a comment |
| 23:33 |
MTDiscord |
<corarona> idk if it's that simple then again it isn't really about who's fault it is |
| 23:33 |
MTDiscord |
<corarona> i will say i have seen many PRs that seemed very promising which ended up going nowhere sometimes because of seemingly trivial stuff |
| 23:34 |
MTDiscord |
<warr1024> MTE's PR queue is not a bin you can just throw code in and say "here you deal with it," it requires active advocacy and maintenance. A PR author must first meet that hurdle, unless they're lucky enough to fix something high priority enough that it can't wait. |
| 23:34 |
[MatrxMT] |
<AncientMariner> faults are not helpful. blame does not solve problems. it does not create improvement |
| 23:34 |
MTDiscord |
<greenxenith> If an author abandons a pr, close it. If devs aren't reviewing a pr and it gets stale, its the devs fault not the author. It shouldn't be closed on that account. |
| 23:34 |
MTDiscord |
<warr1024> The core team has no responsibility to any specific PR, their responsibility is only to the collective. |
| 23:35 |
MTDiscord |
<greenxenith> What exactly is an author supposed to do to get something merged? |
| 23:35 |
MTDiscord |
<greenxenith> Is there a documented process? |
| 23:35 |
[MatrxMT] |
<AncientMariner> agreed, green |
| 23:35 |
MTDiscord |
<warr1024> If a PR is low priority and PRs with higher priority are getting merged, then it's not the fault of the devs doing the reviewing and merging. It's either because the author didn't communicate the priority well enough or convince people it was important, or because the people deciding on priority screwed up. |
| 23:36 |
MTDiscord |
<greenxenith> Even if a pr is low priority it shouldn't be closed simply because no one has gotten to it yet |
| 23:36 |
MTDiscord |
<warr1024> The fact that it's assumed that the same people will be deciding priority and also doing code reviews is ... frankly, kind of weird, for a project this scale. |
| 23:36 |
MTDiscord |
<corarona> something being someones fault kind of implies intent. I do not think any of this is because anyone involved has bad intentions |
| 23:37 |
MTDiscord |
<greenxenith> Closing a pr requires intent |
| 23:37 |
red-001 |
the issue has always been a bad review process that focuses too much on a few core devs having the time to look at the PR. Rust has a process where people are randomly assigned to review PRs. Getting all active contributors to take part in that would get things reviewed quicker |
| 23:37 |
MTDiscord |
<greenxenith> The intent to close a pr when an author is maintaining it but no devs are reviewing is a bad intent |
| 23:37 |
[MatrxMT] |
<AncientMariner> tidying is not bad intent. they intent is to clean, the effect could feel like a slap in the face |
| 23:38 |
MTDiscord |
<wsor4035> zughy usually handles closing prs, but iirc if it has action/change needed label and the author hasnt done anything in a month it gets closed |
| 23:38 |
MTDiscord |
<warr1024> Whether fault implies intent or not, it certainly implies responsibility to correct it. The total amount of responsibility each role/person has should be limited. |
| 23:38 |
red-001 |
it seems fair to not review someones PR unless they for instance review 5 other PRs from other authors |
| 23:38 |
[MatrxMT] |
<AncientMariner> the art of it is to understand what doesn't work, and what changes could be made to improve things |
| 23:38 |
MTDiscord |
<luatic> I would appreciate more contributors partaking in reviews. That's also the path that leads to them becoming core devs in some cases :-) |
| 23:38 |
[MatrxMT] |
<AncientMariner> insanity is doing the same thing and expecting different results |
| 23:38 |
MTDiscord |
<warr1024> We can't have the core team be responsible for reviewing and nurturing and guiding every PR when there is not limit to how many can be thrown at them. They need to be allowed to triage some. |
| 23:38 |
MTDiscord |
<corarona> nah i think the intent is probably to maintain some sense of order i would not say the intent is "you suck your pr is bad, go aways" hehe |
| 23:38 |
MTDiscord |
<warr1024> Haha, lars, you're not exactly upselling it there :-D |
| 23:39 |
MTDiscord |
<greenxenith> When merges are labeled as requiring dev approvals, most contributors don't feel they have any say or use in reviewing |
| 23:39 |
MTDiscord |
<warr1024> "Help out with some reviews, and you can have a bunch of responsibility and be underappreciated too!" |
| 23:39 |
MTDiscord |
<greenxenith> "We are closing your actively maintained pr because we can't keep track of all these prs" |
| 23:39 |
MTDiscord |
<corarona> yeah that is probably a quite important point |
| 23:39 |
red-001 |
it should be everyone's responsibility to review PRs, green is right that people aren't encouraged to do it when it's not considered in merge decisions |
| 23:39 |
[MatrxMT] |
<AncientMariner> maybe there needs to be more focus on groups below core devs, folk trusted to help out and get a pr from horrific into reviewable |
| 23:39 |
MTDiscord |
<warr1024> In order for the community to get involved in reviewing we MAY need to have something like a "needs code review" label specifically, and let people know that that means that it WOULD help. |
| 23:40 |
MTDiscord |
<warr1024> red: "everybody's responsibility" isn't very helpful though, as that often just means nobody's responsibility. |
| 23:40 |
MTDiscord |
<warr1024> Having only core devs and no other role doesn't seem right for a project this size. |
| 23:40 |
red-001 |
well that's why I suggest it's enforced by requiring people review other PRs if they want theirs to be reviewed |
| 23:40 |
MTDiscord |
<luatic> We should probably have more roles |
| 23:41 |
MTDiscord |
<warr1024> Like, there's no steering by gamedevs. How is a project supposed to be successful if it only ever haphazardly gets feedback from its actual users? |
| 23:41 |
[MatrxMT] |
<AncientMariner> core devs can set direction, standards stuff to look out for |
| 23:41 |
[MatrxMT] |
<AncientMariner> and it's almost like a mentoring program for newer high potential folk |
| 23:41 |
[MatrxMT] |
<AncientMariner> who can review |
| 23:41 |
MTDiscord |
<warr1024> I've suggested that there be an official gamedev steering committee at one point but everyone said "oh, that might be a good idea, I guess" and then did jack all about it. |
| 23:41 |
red-001 |
now sure with mandatory reviews, some of those reviews won't be very useful, but making it a requirement to put the minimal effort in requires someone at least tries least they look like they are avoiding their responsibility |
| 23:42 |
[MatrxMT] |
<AncientMariner> very good idea warr. an engine is only as good as it's uses |
| 23:42 |
MTDiscord |
<warr1024> gamedevs are major stakeholders, it only makes sense. A lot of what we do is working around engine bugs and quirks. We also know what kinds of issues we can live with. |
| 23:42 |
MTDiscord |
<corarona> no time i'm busy fixing hud_elem_type :p |
| 23:43 |
[MatrxMT] |
<AncientMariner> prolific modders too |
| 23:43 |
MTDiscord |
<luatic> can the gamedev steering committee please speak up |
| 23:43 |
MTDiscord |
<warr1024> Players have a stake too, though theirs is partly indirect. Things like accessibility, translations, and a lot of main menu stuff (like content browser and server list) affect players directly. A lot of game features like Lua APIs are more things that affect gamedevs. |
| 23:44 |
MTDiscord |
<warr1024> Obvious gamedev steering candidates would include publishers of major games on CDB that are still actively maintained. |
| 23:44 |
MTDiscord |
<luatic> seriously though i think if there was such a group of gamedevs willing to step up, i imagine there'd be less of a hurdle of bestowing them with such a role (though to an extent, they've always had it by virtue of minetest folks recognizing their names...), vs. if we first have to chase after them 😅 |
| 23:45 |
MTDiscord |
<greenxenith> That disqualifies me ;D |
| 23:45 |
[MatrxMT] |
<AncientMariner> i think there are folk that would step up, if they were welcome to step off |
| 23:45 |
[MatrxMT] |
<AncientMariner> you don't step up to get your head knocked off |
| 23:45 |
MTDiscord |
<warr1024> I'm willing to lend my voice, talk about my priorities, etc. I'd need to know about what you actually want from somebody in my role before I can commit to anything specific. |
| 23:45 |
[MatrxMT] |
<AncientMariner> you don't give feedback if you expect a "ahhh, shut up" |
| 23:46 |
[MatrxMT] |
<AncientMariner> or a polite "no" |
| 23:46 |
[MatrxMT] |
<AncientMariner> "no", and "definitely not" to anything anyone says |
| 23:46 |
MTDiscord |
<warr1024> I have time concerns; I take hiatuses from game dev every so often for IRL reasons, so I could participate in meetings but maybe not be in charge of making sure they happen every week or something. |
| 23:46 |
MTDiscord |
<greenxenith> There are also quite a few gamedevs that don't publish games because they can't finish them due to missing engine features.. their input sounds rather valuable |
| 23:47 |
MTDiscord |
<luatic> the "unhappy gamedevs steering committee" unironically sounds like a great idea |
| 23:47 |
MTDiscord |
<warr1024> AM: The MT project has always been sensitive to the risk people have of becoming abuse targets for their involvement in the project, and has pretty careful policies about e.g. maintaining people's pseudonymity and such... |
| 23:47 |
[MatrxMT] |
<AncientMariner> maybe if there is a forum for game devs and modders to discuss what they care about |
| 23:47 |
[MatrxMT] |
<AncientMariner> and it can influence priority labels, that'd be cool |
| 23:47 |
MTDiscord |
<warr1024> Green: if you can identify them, we should throw their names in the hat and invite them. |
| 23:47 |
[MatrxMT] |
<AncientMariner> it would almost be a form of triage too |
| 23:48 |
[MatrxMT] |
<AncientMariner> a way to perculate ideas and come up with a convincing pitch that can cover multiple uses |
| 23:48 |
[MatrxMT] |
<AncientMariner> but without mt approval, it'd be a stealthy union of the disgruntled |
| 23:49 |
MTDiscord |
<warr1024> I mean even something pretty simple, like, each release cycle, each member of the steering committee gets to cast votes on PRs to get prioritized somehow, that would get things started. |
| 23:49 |
[MatrxMT] |
<AncientMariner> turned pitchfork brigade |
| 23:49 |
MTDiscord |
<warr1024> AM: though, never underestimate the MT community's ability to overestimate its own ability to actually organize. Most of us are just sitting at home polishing their own pitchforks. Mine is actually holding up a table leg. |
| 23:50 |
MTDiscord |
<corarona> idk, you can prioritize all you like ultimately someone has to do the work |
| 23:50 |
[MatrxMT] |
<AncientMariner> yeah, but how do you know what to work on if it isn't prioritised |
| 23:50 |
MTDiscord |
<warr1024> Well, if people on the gamedev steering group want to do some actual work too, they're welcome to. |
| 23:50 |
MTDiscord |
<greenxenith> Thats the neat part: We dont |
| 23:50 |
[MatrxMT] |
<AncientMariner> if you have 900 issues, that's weighing up 900 things, if you have 50 highs, that's weighing up 50 |
| 23:50 |
[MatrxMT] |
<AncientMariner> no one can weigh up 900 issues and decide what to work on |
| 23:51 |
[MatrxMT] |
<AncientMariner> maybe it could do with a channel to discuss things |
| 23:51 |
MTDiscord |
<warr1024> Ultimately we can't force people to work on things they really don't want to work on, this IS a hobby project run on volunteer time. All we can do is make it easier for people to pick the things that will give more value. |
| 23:51 |
MTDiscord |
<greenxenith> Not even the devs have any real priorities. There isnt a real vision for the engine or anything. Just a handful of "this could be better for now"s |
| 23:52 |
MTDiscord |
<warr1024> We don't need to actually SOLVE the whole problem yet, just IMPROVING the situation is worthwhile. |
| 23:52 |
[MatrxMT] |
<AncientMariner> "communitee steering group, and folk can suggest ways to go about it, or things they care about, if someone can update that list, organisation can be done ad hoc |
| 23:52 |
MTDiscord |
<corarona> well i mean are there people sitting around a lot thinking "i wonder what i could do, i am so lacking someone giving me priorities here"? |
| 23:52 |
MTDiscord |
<warr1024> Often it's more like "this all looks so daunting, I think I'll go do something else instead" but the effect is much the same. |
| 23:52 |
red-001 |
speaking more on the code side of things, would be nice if someone could get a second review for #15077 or decide it's trivial. It's pretty annoying seeing Visual Studio complain about "security issues" and would require using Windows-only functions to fix. |
| 23:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/15077 -- Disable CRT security warnings in MSVC. by red-001 |
| 23:53 |
[MatrxMT] |
<AncientMariner> some devs often pick up newest issues, even if they are irrelevent |
| 23:53 |
[MatrxMT] |
<AncientMariner> if there was a nice filter for top bugs, or top issues, it's easier to digest |
| 23:53 |
red-001 |
most annoying compiler feature, cmake should have really set the flag by default |
| 23:54 |
|
SFENCE joined #minetest-dev |
| 23:54 |
MTDiscord |
<corarona> well i guess you'll have to find someone who has windows first :p |
| 23:55 |
MTDiscord |
<wsor4035> 15077 is trival enough it could be merged under 1 approval policy |
| 23:55 |
red-001 |
you can just look at the build output from actions https://github.com/minetest/minetest/actions/runs/10623319320/job/29449510847?pr=15077 @corarona |
| 23:56 |
MTDiscord |
<wsor4035> if you want to rank things, label + thumbs up does a decent job, isnt perfect though https://github.com/minetest/minetest/issues?q=is%3Aopen+is%3Aissue+label%3ABug+sort%3Areactions-%2B1-desc for example |
| 23:56 |
MTDiscord |
<warr1024> As an experiment, we could just invite a bunch of people (like maybe a dozen) pulled from active gamedevs, and allow each one to vote on ONE issue or PR. Then the triage team tallies up the votes and picks some reasonable number of those issues from the top to get some kind of high priority label. Core devs can have their own high priority items based on what is causing them the most trouble. Then we generally agree to at least try |
| 23:56 |
MTDiscord |
to work on high priority stuff first, where work is being done. |
| 23:57 |
[MatrxMT] |
<AncientMariner> perhaps more than 1 vote, 3, as most just vote for their own, 3 would probably encourage concensus |
| 23:58 |
[MatrxMT] |
<AncientMariner> 2 of your votes have to be for an issue raised by another project ;) |
| 23:58 |
MTDiscord |
<warr1024> Sure, exact number of votes isn't a major factor, though it'd be nice to be able to put multiple votes on a single item. |
| 23:58 |
MTDiscord |
<wsor4035> can i object to this on grounds that i dont want to do more minetest stuff? /s |
| 23:58 |
MTDiscord |
<corarona> make preferential voting |
| 23:59 |
[MatrxMT] |
<AncientMariner> preferential can be more time consuming to tally than just adding up though |
| 23:59 |
red-001 |
select a jury of world citizens and have them decide /j |
| 23:59 |
MTDiscord |
<warr1024> The reason why the steering group idea is important and I'm skeptical about just counting 👍 from the community is that there's a difference between "if you complete this item, I have a major feature based on it planned "and "if you complete this item, I bet somebody could do something neat with it someday." Things that have speculative value are cool and all, but things that are actually holding back real development today should |
| 23:59 |
MTDiscord |
be first. |
| 23:59 |
[MatrxMT] |
<AncientMariner> yup. we've decided. take your proprietary windows, proprietary ms software, and stay out! :) |
| 23:59 |
MTDiscord |
<luatic> 👍 |
