00:10:43 Stable (0.32) branch on cbro.berotato.org updated to: 0.32.0-11-ga5df4b8d09 05:01:06 Stable (0.32) branch on crawl.akrasiac.org updated to: 0.32.0-11-ga5df4b8 05:07:14 Unstable branch on crawl.akrasiac.org updated to: 0.33-a0-52-g7029d37 (34) 06:23:07 ChongLi (L21 MDNe) Crash caused by signal #11: Segmentation fault (Vaults:5) 06:38:45 !crashlog ChongLi xl=21 MDNe 06:38:46 1. ChongLi, XL21 MDNe, T:47194 (milestone): https://cbro.berotato.org/morgue/ChongLi/crash-ChongLi-20240908-132253.txt 06:45:45 so, what should happen if _get_shadow_spots() produces an empty Vector? 06:46:08 (it checks range 2-3, then adjacent; map snapshot shows the player 4-deep in Zs 06:46:11 ) 06:55:39 New branch created: pull/4016 (1 commit) 13https://github.com/crawl/crawl/pull/4016 06:55:40 03geekosaur02 07https://github.com/crawl/crawl/pull/4016 * 0.33-a0-53-g49ad4943fc: don't crash if shadow can't be placed (ChongLi) 10(4 minutes ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/49ad4943fc94 06:56:45 03geekosaur02 07https://github.com/crawl/crawl/pull/4016 * 0.33-a0-53-g823d428bf3: don't crash if shadow can't be placed (ChongLi) 10(5 minutes ago, 1 file, 6+ 1-) 13https://github.com/crawl/crawl/commit/823d428bf3aa 07:13:34 <12g​e0ff> re: community reviews. I'm glad that this small article led to a discussion about handling contributions and to closing/commenting on a whole bunch of PRs. But it seems like even those who read it missed the point, focusing on controversial PRs and on old PRs instead. 07:13:41 <12g​e0ff> So please let me go through this one more time with a real example. 07:13:52 <12g​e0ff> A lot of DCSS PRs are both small and non-controversial, but handling them still requires dev time. The question is "can the contributors help the devs here?" 07:14:00 <12g​e0ff> Let's imagine, just for the sake of argument, that I'm an experienced contributor. 07:14:11 <12g​e0ff> I notice a PR that is small, non-controversial, and which is something I myself need in the game, like https://github.com/crawl/crawl/pull/3981 ("Don't let non-damaging walls or clouds stop running.") 07:14:18 <12g​e0ff> I look at the code, fetch this PR, test it locally with Qaz, Jiyva, salamander armour, catoblepas' clouds and Gr, and so on, and find that it does indeed fixes the bug. 07:14:24 <12g​e0ff> I leave a comment on the PR, saying that I tested it and the code looks fine and add a "contributor-approved" tag on the PR if that's needed. 07:14:52 <12g​e0ff> 1. Does such review make a dev's life easier and, specifically, does it save your dev time? 07:15:01 <12g​e0ff> 2. Do you want more of such community reviews from experienced contributors? 07:15:03 <12g​e0ff> 3. And if you answer "yes" to both questions, does the approach from the article seem suitable, and how it could be tailored for DCSS? 07:18:15 GH's review system works fine for that kind of thing. reviews by users without write access to the repo don't count for "reviews-required" branch protection settings, but are still counted 07:19:53 fwiw I also go in the other direction, I look over at least some of the PRs that come in and comment on any issues I notice 07:20:39 which saves a dev having to take time to do it, the PR is more likely to be in a directly usable state 07:23:17 <12g​e0ff> Yeah, things like helping other contributors by pointing them to commit conventions can totally be done by other contributors. You don't need a mega-busy dev for that! 11:28:50 <04d​racoomega> I don't know if this is a 'me' problem, but I think the truth of the matter - for me specifically, at least - is that even if a community member said they had tested a PR and confirmed it works - that if I were the one merging the code myself, I would still feel responsible for doing that again myself anyway. That by signing off on something, I am taking personal responsibility for it. That's not to say that it isn't helpful 11:28:50 to have other sets of eyes on things - at the very least, there's a chance of catching problems a dev might still overlook - but it's not immediately clear to me how much this would actually expedite things. Maybe a little? This feels like an unsatisfying answer, I'm sure. =/ (Yes, helping to fix 'objective' problems where they exist is time-saving, I guess.) 11:29:52 <04d​racoomega> Suddenly wondering what ratio of PRs I personally look over get deferred because of time/effort needed to properly test (that I either don't have at the time, or are opting to spend on other things) or because there is something less objective about the PR itself that I'm hesitant about (whether from a design or implementation standpoint). Like "Do I think this is actually a good idea?" and "Do I like the approach they've taken in 11:29:52 their code at all?" where there isn't something instant I can point to as objectively wrong about it, and yet... I'm not really sure. 11:31:41 <04d​racoomega> (I 'should' be commenting on PRs in a bunch of these cases, I realize. It's an... interpersonal hesitancy thing, let's call it. That's on me, I realize, but also... non-trivial to change, y'know? >.>) 11:32:10 <06p​leasingfungus> yeah, +1 on feeling the need to personally review 13:25:22 <12g​e0ff> To paraphrase a Star Wars character, "The power to delegate is a pathway to many abilities some consider to be unnatural." 🙂 Although, if you prefer to check contributions yourself, it's totally understandable and I'm not gonna push this question further. 14:20:52 03Samantha Tobias02 {regret-index} 07* 0.33-a0-53-g9043e79ccf: fix: "Ran out of altars for temple" error (thirdmesn, Vajrapani) (#4005) 10(5 days ago, 2 files, 10+ 8-) 13https://github.com/crawl/crawl/commit/9043e79ccf94 14:20:53 03Samantha Tobias02 {regret-index} 07[stone_soup-0.32] * 0.32.0-12-g91f736bfdd: fix: "Ran out of altars for temple" error (thirdmesn, Vajrapani) (#4005) 10(5 days ago, 2 files, 10+ 8-) 13https://github.com/crawl/crawl/commit/91f736bfdd2a 14:42:07 <02M​onkooky> I feel like there's still useful triage to do 15:39:08 Unstable branch on underhound.eu updated to: 0.33-a0-53-g9043e79ccf (34) 20:52:47 -!- robin is now known as lispwitch 20:52:57 -!- lispwitch is now known as robin 20:54:29 <08n​icolae> i wonder if a stopgap for the thing where you can't do multiple vault redefines, like you can't have regular trees and dead trees in one vault, would be to define metal_statue_2 and tree_2 that are the same as the regular features but you get to do a second redefine on 'em 20:59:41 <06p​leasingfungus> noo 21:19:26 <06r​egret-⸸nde※> I'd be extremely reluctant to shove something into the enum history forever (or until we accidentally break save compat). 21:19:57 <04d​racoomega> I am also very much not a fan of that idea, from a technical perspective (not even for the fact that we'd be stuck with it, but more like "It seems woefully awful to have to treat pairs of these features as identical in code everywhere the cares about them") 21:20:17 <06r​egret-⸸nde※> It is a state of affairs I'm not the happiest with, but dead -> petrified or dead -> demonic still work for other purposes. 21:20:46 <04d​racoomega> (It would be nice for that vault redefines issues to be fixed, of course, but I think it's actually kind of a pain in the ass and would need some rewriting) 21:21:39 <04d​racoomega> Since I believe vaults store redefines internally as a 'feature->definition' that is vault-wide and this would need to be able to do it per tile instead. Not impossible, but a non-trivial amount of refactoring 21:21:55 <06r​egret-⸸nde※> (I do have to admit I haven't leapt onto spreading out those 40-something submitted decor tiles because I don't have the easiest answer beyond having a single "decor" object, but even that's easier to excuse because it'd be essentially floor 2 in comparison.) 21:22:56 <06r​egret-⸸nde※> (I do have to admit the limitations are nice in a certain design fashion when it means somebody can't just place 10 different conduits into one vault and call that A Theme, though.) 22:07:15 Stable (0.32) branch on underhound.eu updated to: 0.32.0-12-g91f736bfdd 22:35:15 Unstable branch on crawl.develz.org updated to: 0.33-a0-53-g9043e79ccf (34) 22:58:21 Windows builds of master branch on crawl.develz.org updated to: 0.33-a0-53-g9043e79ccf 23:13:23 Unstable branch on cbro.berotato.org updated to: 0.33-a0-53-g9043e79ccf (34) 23:55:37 Monster database of master branch on crawl.develz.org updated to: 0.33-a0-53-g9043e79ccf