Time Nick Message 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. 08:14 [MTMatrix] 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 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 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 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 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:12 MTDiscord (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 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) 11:28 rubenwardy Yeah exactly 11:28 rubenwardy 2 also leads to more 2, as releases get further apart 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 12:33 MTDiscord 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 And then release minor versions more avidly. 12:34 MTDiscord 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 (and if it wasn't so hot in the last days that I can barely think) 12:36 MTDiscord 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 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. 13:22 MTDiscord 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 15:56 MTDiscord 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 MTDiscord 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. 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 Ultimately people need to learn to make compromises. Our bikeshed arguments last forever because there are too many conflicting purists involved. 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 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 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 18:41 MTDiscord 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 (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 You know 18:50 MTDiscord 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 Call it, unstable build or something and link it in the downloads for people that like to fly on the edge 18:59 MTDiscord https://nightly.link/minetest/minetest/workflows/windows/master/mingw64.zip 19:00 MTDiscord (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] 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 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 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: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 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 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 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 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 😦 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 Guess ill bump it up on my priority list 21:16 mtvisitor Zughy: thank you. 21:16 mtvisitor https://www.coursera.org/articles/triple-constraints-of-project-management 21:17 [MTMatrix] 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 from us when he is young. 21:22 MTDiscord 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. 🀝🍺🍻