Time Nick Message 11:37 MTDiscord i am definitely not the fatest 14:45 [MTMatrix] 100 PRs again :( 15:52 MTDiscord Would you prefer 101? I could make that happen after dinner maybe. 15:54 pgimeno I'd like to propose a slightly different workflow: permanent feature freeze (disclaimer: IANACD). It would work like this: after release, every feature PR that is ready is automatically merged, and the rest of the release time is dedicated to letting people test it, fixing bugs, reviewing other features as they appear, and so on. 15:56 pgimeno The advantage is that it would give more testing time to new features, and hopefully reduce release time. 16:18 [MTMatrix] people don't test PRs. The fastest way for a test is to put them in a release 16:19 [MTMatrix] RE josiah_wi: I'd prefer another core dev 16:20 Krock testing PR's is best done with a Release Candidate, which would also be an option for 5.9.0 16:21 Krock pgimeno: this would definitely be the fastest way to proceed, yes. I'd like to bring this up in the meeting. Editing the wiki ....ΓΆ 16:22 pgimeno @Zughy OK but does that have something to do with my proposal? if so, maybe you have misunderstood it? 16:44 [MTMatrix] RE pgimeno: you said "and the rest of the release time is dedicated to letting people test it". What people exactly? Core devs aside, I don't think many people would actually give it a try 16:46 Krock it's not so many but those who do it are the most helpful ones in opening issues 17:01 [MTMatrix] you might be right. Another doubt: wouldn't this provoke a rush for debatably written feature PRs, since the goal is to have them published before a release? 17:03 Krock only if release cycles are bianually 17:04 Krock it would work best with a release every two months 17:04 Krock or maybe every month 17:05 Krock rebase hell would come sudden, though. 17:10 pgimeno it's pretty much the same as now, with the difference that the merge date for feature PRs is moved to immediately after the release, and all are merged at the same time. I believe many people are using the devel version; that would give those people time to test all the new features. 17:13 pgimeno Rushed PR's would still need two approvals, which might take a while, especially if they are bad quality. I don't think people would try to squeeze them into the release. But that might be me. 17:16 Krock I can be rather picky at times so don't worry much about quality :3 17:19 [MTMatrix] pgimeno: fair point 17:19 [MTMatrix] I think 3 months are a good compromise 17:20 [MTMatrix] wait: wouldn't that cause a rebase hell? 17:21 [MTMatrix] Like, if you have 20 PRs ready to go in, there will be definitely PRs touching the same part of code 17:24 pgimeno maybe, that's something Krock has mentioned, but good luck getting 20 PRs ready to merge at once :) 22:06 MTDiscord Lars has been doing a lot of reviews. I don't know that I have the domain knowledge required to review any of the graphics stuff. 22:08 MTDiscord I could review anything that has nothing to do with graphics or OS specific stuff, probably. 22:10 MTDiscord https://github.com/minetest/minetest I would approve right now if not for the weird formatting thing, for example. 22:11 MTDiscord Waaait nevermind. 22:11 MTDiscord He did weird stuff. 22:11 MTDiscord currently looking at some PRs, will go back to exam prep tomorrow 22:11 MTDiscord it appears you just sent a link to the minetest repo josiah? 22:13 MTDiscord Whoops. 22:13 MTDiscord Here wo go: https://github.com/minetest/minetest/pull/14864. 22:14 MTDiscord That's alright, everyone makes mistakes 22:14 MTDiscord I finished looking through this. The PR has an unfortunate name but yes this looks like an immediate approval. 22:15 MTDiscord Maybe since we don't have an automated formatter and the formatting change is consistent with the style guide we just ignore it. 22:15 MTDiscord Hmm. 22:17 MTDiscord Heh, I just commented on that PR. I'm not really happy with it yet, primarily because I don't see the issue in the first place (what is the code path where uninitialized data is being read and why?), and I'm not yet convinced that this fixes it in a proper way. 22:18 MTDiscord I'm glad you called out that it could indicate a real bug. We want to do this either way, though. 22:18 MTDiscord I think the issue he's trying to fix is that there's a compiler warning. That's an issue in itself. 22:18 MTDiscord This is a failing run-time check as far as I understood 22:21 MTDiscord Oh interesting. 22:22 MTDiscord This is why I'm not a core dev. πŸ™‚ 22:22 MTDiscord (Or maybe it's because I'm pair debugging a race condition at the same time.) 22:23 MTDiscord multitasking is tricky πŸ˜… 22:24 MTDiscord I suppose I ought to be able to reproduce the bug as well. 22:27 MTDiscord In any case, my suggestion would be to merge this and leave the issue open. 22:27 MTDiscord It shouldn't be called a "fix" since it isn't. It's just a code quality update. 22:49 [MTMatrix] luatic: any chance to see comments in the limited observers PR addressed? 22:52 MTDiscord Is there any process whereby core devs are assigned to review PRs? It might help chip away at the number of PRs over time. 22:53 MTDiscord At ATS we meet once a week and try to stay under 1 page of open PRs (currently at 20). A non-funded project could probably meet much less frequently. 22:54 MTDiscord Zughy: I don't want to get your hopes up, but in about a week I can probably get to it (after I have finished the second exam I plan on taking in this first period). 22:55 MTDiscord (There's technically a third and a fourth after that, but they are harder math exams I plan on taking in the second period anyways.) 22:58 [MTMatrix] josiah_wi: what's ATS? 23:02 MTDiscord Apache Trafficserver; I am a paid contributor. 23:02 MTDiscord I guess I haven't mentioned that in the IRC bridges before.