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 wrote:

Richard Eisenberg mailto:lists@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

On Feb 10, 2022, at 3:25 AM, Sven Tennie wrote:

What do you think about the idea of having a Hadrian target ready-for-ci (or something like this) that would run all simple checks?

That could work. But my experience with the current linters is that local execution gives different results than the execution in CI. Somehow, the CI execution is clever enough to flag only new breakages (or breakages in files that have been touched, perhaps), whereas when I've run existing linters locally, I get a slew of reports that are unrelated to my work. I suppose the same problem could come up if the linters are in the testsuite, though. Richard

Just to add to this. I think we should *optimize* for people not working full time on GHC. Anything that's going to be smooth for people working only a few hours a week on GHC will implicitly improve the situation for those working more hours on GHC as well. As in what is pleasant for someone with little time should also make it pleasant for someone with lots of time. I don't see why marge would be an issue though? If we allow all failures, why would someone assign something to marge that still *has* failures? Isn't the idea that you assign to marge once you've cleaned up all failures? I mean ideally we'd want to get a summary of all failures (without the noise). The only drawback I can see is this: if we allow all failures, and then end up with lots of MRs, we might run into build constraints (e.g. you are going to wait hours for your MR to even be picked up by the fleat of CI machines). I don't see this happening immediately. And maybe if this happens we can get ~7k EUR / year form the HF? That's about as much as the builders I provide cost per year. Cheers, Moritz On Thu, 10 Feb 2022 at 10:04, Ben Gamari wrote:

Richard Eisenberg 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