<div dir="ltr">Just to add to this. I think we should *optimize* for people not working full time on GHC.<div>Anything that's going to be smooth for people working only a few hours a week on GHC</div><div>will implicitly improve the situation for those working more hours on GHC as well. As in<br>what is pleasant for someone with little time should also make it pleasant for someone<br>with lots of time.<br><br>I don't see why marge would be an issue though? If we allow all failures, why would<br>someone assign something to marge that still *has* failures? Isn't the idea that you</div><div>assign to marge once you've cleaned up all failures?<br><br>I mean ideally we'd want to get a summary of all failures (without the noise).<br><br>The only drawback I can see is this: if we allow all failures, and then end up with lots<br>of MRs, we might run into build constraints (e.g. you are going to wait hours for your<br>MR to even be picked up by the fleat of CI machines). I don't see this happening</div><div>immediately.¬† And maybe if this happens we can get ~7k EUR / year form the HF?<br>That's about as much as the builders I provide cost per year.<br><br>Cheers,<br>¬†Moritz<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Feb 2022 at 10:04, Ben Gamari <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</a>> writes:<br>
<br>
> Hi devs,<br>
><br>
Hi Richard,<br>
<br>
> Can we please, please not have the linters stop more useful output<br>
> during CI? Over the past few months, I've lost several days of<br>
> productivity due to the current design.<br>
<br>
Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle.<br>
<br>
> Why several days? Because I typically end up with only 1.5-2 hours for<br>
> GHC work in a day, and when I have to spend half of that recreating<br>
> test results (which, sometimes, don't work, especially if I use<br>
> Hadrian, as recommended), I often decide to prioritize other tasks<br>
> that I have a more reasonable chance of actually finishing.<br>
><br>
> It was floated some time ago that "Draft" MRs could skip linters. But<br>
> I actually have a non-Draft MR now, and it failed the new Notes<br>
> linter. (Why, actually, is that even a separate pass? I thought there<br>
> was a test case for that, which I'm thrilled with.)<br>
><br>
It's a separate pass to help the contributor distinguish <br>
<br>
> It just feels to me that the current workflow is optimized for those<br>
> of us who work on GHC close to 100% of the time. This is not the way<br>
> to get new contributors.<br>
><br>
Yes, I am sympathetic with this concern. One alternative design that we<br>
could try is to rather allow linters to fail *except* in Marge jobs.<br>
This would mean that we would need to be very careful not to pass jobs<br>
with failing lints to Marge as doing so would spoil the entire Marge<br>
batch. However, it would also mean that it would make contribution in a<br>
less-than-full-time setting a bit easier. How does this sound?<br>
<br>
If we had more devops capacity we could mitigate the Marge-spoilage<br>
problem by teaching Marge not to consider MRs which are failing lints.<br>
However, at the moment I don't think we have the bandwidth to implement<br>
this.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>