the linters are killing me slowly

[Richard Eisenberg]

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?

Thanks,
Richard

> 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
> this.
> 
> Cheers,
> 
> - Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220210/06d88b93/attachment.html>