| Time |
Nick |
Message |
| 01:19 |
|
Noisytoot joined #minetest-dev |
| 01:19 |
|
MTDiscord joined #minetest-dev |
| 01:31 |
|
ivanb joined #minetest-dev |
| 01:38 |
|
Noisytoot joined #minetest-dev |
| 01:52 |
|
Noisytoot joined #minetest-dev |
| 02:04 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:01 |
|
Noisytoot joined #minetest-dev |
| 04:47 |
|
d0p1 joined #minetest-dev |
| 05:07 |
|
Noisytoot joined #minetest-dev |
| 05:14 |
|
Noisytoot joined #minetest-dev |
| 05:22 |
|
fluxionary joined #minetest-dev |
| 05:32 |
|
Noisytoot joined #minetest-dev |
| 05:44 |
|
cranez joined #minetest-dev |
| 05:51 |
mtvisitor |
there is 1 more comment. |
| 05:53 |
mtvisitor |
after the minetest engine (MTE) v5.9 released with release notes, please try to finalize MTE's v5.10 scope before starting the engine development. |
| 05:53 |
mtvisitor |
think before development if possible. |
| 05:57 |
|
Noisytoot joined #minetest-dev |
| 06:05 |
|
Noisytoot joined #minetest-dev |
| 06:29 |
|
cranez joined #minetest-dev |
| 07:29 |
|
Pexin joined #minetest-dev |
| 08:14 |
[MTMatrix] |
<Zughy> I agree, especially if we're going for smaller dev cycles. Agreeing on a few key aspects so to have a raw planning would be good both for us and the community |
| 08:30 |
|
Noisytoot joined #minetest-dev |
| 09:02 |
rubenwardy |
we did that for 5.9. The goal of 5.9 was SDL2 |
| 09:02 |
rubenwardy |
I believe also glTF but that wasn't really achievable given we were waiting on contributor time |
| 09:08 |
MTDiscord |
<herowl> Talking from VL experience, planning doesn't lead to shorter release cycles, what leads to shorter release cycles is releasing (or feature-freezing) once whatever issues arose from the last update seem to be resolved, and merging whatever features are done along the way. |
| 09:11 |
MTDiscord |
<herowl> Planning is good in terms of eg. "We bring that large feature (eg. Gltf or SDL2 or whatever) in once it's finished in its own branch. It may be multiple PRs that target and improve and fix that branch that are reviewed and merged into it along the way." |
| 09:11 |
MTDiscord |
<herowl> In other words, planning speeds up the release cycle if it lets you release without the large feature, not if it makes you wait for it. |
| 09:11 |
|
Noisytoot joined #minetest-dev |
| 09:12 |
MTDiscord |
<herowl> (without the large feature and without undoing tons of changes that may have unintended side effects and everyone just prefers to wait and fix it up rather than reverting commits) |
| 09:17 |
rubenwardy |
the idea of continuous delivery and release early; release often is precisely to release more frequently without waiting for big milestone changes |
| 09:44 |
|
Noisytoot joined #minetest-dev |
| 10:42 |
celeron55 |
the optionsa are 1) release whatever is ready, or 2) release whenever it's ready |
| 10:42 |
celeron55 |
1 is fast, 2 is slow. pick one |
| 10:43 |
celeron55 |
(when anyone asks me, i always vote for 1) |
| 10:49 |
|
Noisytoot joined #minetest-dev |
| 10:54 |
|
Noisytoot joined #minetest-dev |
| 11:10 |
|
Noisytoot joined #minetest-dev |
| 11:28 |
rubenwardy |
Yeah exactly |
| 11:28 |
rubenwardy |
2 also leads to more 2, as releases get further apart |
| 11:31 |
|
Noisytoot joined #minetest-dev |
| 11:44 |
sfan5 |
I also support 1 |
| 11:49 |
sfan5 |
unfortunately it easily turns into 2 when we have regressions that need addressing |
| 11:53 |
rubenwardy |
Simple fix, don't make regressions |
| 11:53 |
rubenwardy |
No inventory code changes |
| 11:57 |
|
Noisytoot joined #minetest-dev |
| 11:58 |
|
sugarbeet joined #minetest-dev |
| 12:33 |
MTDiscord |
<herowl> Sometimes regressions will still pull you back... looking for regressions too much isn't worth it, or trying to reproduce rare weird regressions. |
| 12:34 |
MTDiscord |
<herowl> And then release minor versions more avidly. |
| 12:34 |
MTDiscord |
<herowl> We're trying to do more of it in VL, we probably would have another release out already if I wasn't so busy for the last month. |
| 12:35 |
MTDiscord |
<herowl> (and if it wasn't so hot in the last days that I can barely think) |
| 12:36 |
MTDiscord |
<herowl> The only regressions that absolutely should never get into a release (i.e. need to be searched for) are regressions that break data in a way that makes it hard (or worse) to recover. |
| 12:39 |
MTDiscord |
<herowl> If there's a rare crash (that still calls data saving and leaves a well-defined state behind) or some media stop working sometimes, and the exact reason/fix for the bug can't be found, a release and then a minor release with a patch (because hopefully more users will give more reports and better insight) is the better course. |
| 12:41 |
|
Noisytoot joined #minetest-dev |
| 12:54 |
|
Noisytoot joined #minetest-dev |
| 13:01 |
|
Noisytoot joined #minetest-dev |
| 13:22 |
MTDiscord |
<exe_virus> yep, my vote is always 1. And if it turns into 2, then everyone is happy. 2 can never be 1 😉 |
| 13:26 |
celeron55 |
another way to think about regressions is that master has accidentally turned into a feature branch |
| 13:27 |
celeron55 |
in that way of thinking, it's sometimes possible to re-extract the feature branch out of it and go on with the rest |
| 13:28 |
celeron55 |
but, it takes away the "release whatever is there" convenience |
| 14:42 |
|
MTDiscord1 joined #minetest-dev |
| 14:51 |
|
[MTMatrix] joined #minetest-dev |
| 15:56 |
MTDiscord |
<herowl> Tbh that should be saved for exceptions. Features shouldn't be merged until ready, and still they shouldn't be as hard to merge as they currently are. I think a solution is that for each PR there should be requirements set (aside of not causing regressions), to avoid further bikeshedding, which is what causes most of the rebase hell (and possibly abandonment/closing) – a PR can't be finished if it's unclear what it should look like |
| 15:56 |
MTDiscord |
when finished. |
| 15:58 |
|
MisterE1230 joined #minetest-dev |
| 15:58 |
MTDiscord |
<warr1024> A fair amount of the reason why PRs get killed by endless bikeshedding is because people are trying to skip the endless bikeshedding of issues by just making a PR, but it doesn't work. |
| 16:49 |
|
[MTMatrix] joined #minetest-dev |
| 17:00 |
celeron55 |
bikeshedding needs to happen, but it should happen efficiently |
| 17:06 |
Mantar |
it's true, sometimes you reach the point where you do have to build a shed for the bike |
| 17:06 |
Mantar |
but you gotta have those arguments when they're relevant, and at some point somebody has to make a final decision |
| 17:08 |
MTDiscord |
<warr1024> Ultimately people need to learn to make compromises. Our bikeshed arguments last forever because there are too many conflicting purists involved. |
| 17:23 |
|
fluxionary joined #minetest-dev |
| 17:27 |
celeron55 |
one could try scheduling a meeting and assign a chairperson for it, so that 1) there's limited time, 2) one person writes down the final decision at the end |
| 17:28 |
celeron55 |
but, i don't know how well that could ever work in this environment |
| 17:28 |
celeron55 |
the dev meetings have been a mixed bag |
| 17:29 |
celeron55 |
(so, to put it positively, sometimes it does work) |
| 17:32 |
MTDiscord |
<warr1024> that would have limited benefit if people's attitudes can't be improved. Even if you can force a decision that way, you won't be able to build consensus around it, and that will hinder progress. |
| 17:32 |
MTDiscord |
<warr1024> I think people just undervalue having a solution, even if it's ugly. |
| 17:33 |
celeron55 |
well i think mostly some people are just loud, and will roll with any decision once they see it's been made and no input will be taken anymore. mostly. not always |
| 17:36 |
celeron55 |
the core team exists so that the people who make most decisions have a bit of responsibility to go with it |
| 17:43 |
|
hlqkj joined #minetest-dev |
| 18:33 |
|
Noisytoot joined #minetest-dev |
| 18:39 |
|
Noisytoot joined #minetest-dev |
| 18:41 |
MTDiscord |
<herowl> I agree that once a decision is made and it is clear it won't be changed anymore, the loud opposition goes silent. This is how it was with VL rename. Some people opposed the idea of renaming at all, some attacked all the names proposed, some actually argued which of the options is better, some opposed the name that got picked... The final name wasn't my best choice either, but it was the most popular with a margin and we went with it. |
| 18:42 |
MTDiscord |
<herowl> (afterthought: "my best choice" may be unclear, I meant that it wasn't what I'd choose personally if it all depended on my choice only) |
| 18:49 |
MTDiscord |
<jordan4ibanez> You know |
| 18:50 |
MTDiscord |
<jordan4ibanez> There's the daily build thing, why not just make a link for it using js or whatever is the backend for minetest.net so everyone can try out the latest builds without having to search for it |
| 18:50 |
MTDiscord |
<jordan4ibanez> Call it, unstable build or something and link it in the downloads for people that like to fly on the edge |
| 18:58 |
|
Noisytoot joined #minetest-dev |
| 18:59 |
MTDiscord |
<rollerozxa> https://nightly.link/minetest/minetest/workflows/windows/master/mingw64.zip |
| 19:00 |
MTDiscord |
<rollerozxa> (github workflows doesn't allow you to download artifacts when not logged in. nightly.link however allows you to get around it and also provides a permalink for the latest artifact built) |
| 19:29 |
[MTMatrix] |
<Zughy> I've scheduled a meeting for this Sunday, to hopefully speed up 5.9. I understand it's summer, but you can never know |
| 19:50 |
MTDiscord |
<greenxenith> <celeron55> well i think mostly some people are just loud, and will roll with any decision once they see it's been made Heh ... me. Sometimes. I think I am just afraid a poor decision will lead to misery later because "we can fix it later if its bad" doesnt work when we wait to the point of "now its a breaking change or it takes monumental effort to undo" |
| 19:54 |
MTDiscord |
<greenxenith> Like the adoption of my water shaders ... I shouldnt really have a problem with it being merged, I just dont like the idea of adding yet more client things that should be game-controlled |
| 20:15 |
|
Noisytoot joined #minetest-dev |
| 20:26 |
|
rubenwardy joined #minetest-dev |
| 20:42 |
celeron55 |
i didn't know about nightly.link, that's quite handy |
| 20:44 |
celeron55 |
greenxenith: i haven't followed your water shader work for some time. what's the status of it? |
| 20:45 |
MTDiscord |
<greenxenith> I was waiting for the Visual Effects Vol 1 PR to be merged before rebasing and merging some fixes from other people, but someone adopted it recently. |
| 20:45 |
MTDiscord |
<greenxenith> I was also considering writing a material API instead of just PRing my water shaders |
| 20:47 |
celeron55 |
well, you could draft a material api, define the default values to be the ones your water shaders use and not implement setting any values yet 8) |
| 20:48 |
MTDiscord |
<greenxenith> The adopters are running into the funny problem of "lava is a liquid and therefore the shader counts it as water" which is ridiculous. The naive "solution" is giving water-grouped nodes their own material (bad awful terrible idea). The proper solution is implementing a BSDF-like structure for nodes to define their own materials for client shaders to render (skipping the hassle of server-sent shaders for now) |
| 20:48 |
MTDiscord |
<greenxenith> Haha, you're not wrong |
| 20:48 |
celeron55 |
i think you know what to do. i hope you find the time to do it |
| 20:48 |
MTDiscord |
<greenxenith> 😦 |
| 20:50 |
celeron55 |
just do the bare minimum to allow future development |
| 20:50 |
celeron55 |
and to allow defining lava to not look like water |
| 20:50 |
celeron55 |
and it's as perfect as it needs to be |
| 20:51 |
MTDiscord |
<greenxenith> Guess ill bump it up on my priority list |
| 21:15 |
|
cranez joined #minetest-dev |
| 21:16 |
mtvisitor |
Zughy: thank you. |
| 21:16 |
mtvisitor |
https://www.coursera.org/articles/triple-constraints-of-project-management |
| 21:17 |
[MTMatrix] |
<Zughy> yep but we're not a company, probably half of the things won't work |
| 21:18 |
mtvisitor |
the project manager may need to compromise and coordinate the scope, time and cost according to the stakeholders requirements. |
| 21:19 |
mtvisitor |
this is just some kind of project management methodology. |
| 21:20 |
mtvisitor |
you are correct, open source projects may be different with the commercial software products. |
| 21:21 |
* mtvisitor |
also like the soap opera <growing pains> from us when he is young. |
| 21:22 |
MTDiscord |
<luatic> something which i should probably share here: i'll be unavailable until the 27th, maybe longer due to exams. i expect to have some time after the 2nd august. |
| 21:29 |
mtvisitor |
who is the fatest? we could take some pictures later. 🤝🍺🍻 |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:38 |
|
Noisytoot_ joined #minetest-dev |
| 23:42 |
|
Noisytoot joined #minetest-dev |
