the linters are killing me slowly
lists at richarde.dev
Thu Feb 10 03:27:06 UTC 2022
Thanks for the response, Ben; it was more measured than my email. :) I have had a string of days when seemingly basic tasks in Haskell failed, all for different reasons. And I suppose I knew that this list would be forgiving of any trespasses.
I do think there is a very happy resolution to all of this: put these lint checks in the testsuite. I believe that was Matthew's idea in yesterday's call, and I think that solves the problem very nicely. Errors get reported concurrently with other errors, a contributor can run the checks locally, and it seems possible to get the linters runnable even without a built GHC. (For example, even if the testsuite requires building GHC, the lint tests can call some lint-ghc script. But, of course, contributors can call lint-ghc directly, too.)
Would that satisfy our needs here?
> On Feb 9, 2022, at 9:04 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> writes:
>> Hi devs,
> Hi Richard,
>> Can we please, please not have the linters stop more useful output
>> during CI? Over the past few months, I've lost several days of
>> productivity due to the current design.
> Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle.
>> Why several days? Because I typically end up with only 1.5-2 hours for
>> GHC work in a day, and when I have to spend half of that recreating
>> test results (which, sometimes, don't work, especially if I use
>> Hadrian, as recommended), I often decide to prioritize other tasks
>> that I have a more reasonable chance of actually finishing.
>> It was floated some time ago that "Draft" MRs could skip linters. But
>> I actually have a non-Draft MR now, and it failed the new Notes
>> linter. (Why, actually, is that even a separate pass? I thought there
>> was a test case for that, which I'm thrilled with.)
> It's a separate pass to help the contributor distinguish
>> It just feels to me that the current workflow is optimized for those
>> of us who work on GHC close to 100% of the time. This is not the way
>> to get new contributors.
> Yes, I am sympathetic with this concern. One alternative design that we
> could try is to rather allow linters to fail *except* in Marge jobs.
> This would mean that we would need to be very careful not to pass jobs
> with failing lints to Marge as doing so would spoil the entire Marge
> batch. However, it would also mean that it would make contribution in a
> less-than-full-time setting a bit easier. How does this sound?
> If we had more devops capacity we could mitigate the Marge-spoilage
> problem by teaching Marge not to consider MRs which are failing lints.
> However, at the moment I don't think we have the bandwidth to implement
> - Ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs