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 <b...@smart-cactus.org> wrote: > > Richard Eisenberg <li...@richarde.dev <mailto:li...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs