[GHC DevOps Group] CircleCI job accounting question

[Manuel M T Chakravarty]

Hi Ben,

> Am 12.12.2017 um 02:22 schrieb Ben Gamari <ben at well-typed.com>:
> 
> Simon Peyton Jones <simonpj at microsoft.com> writes:
> 
>> The problem is that many contributors, including Simon PJ, Richard, and
>> me, tend to push batches of work
>> 
>> I have not been following this thread (“job accounting” seemed above
>> my pay grade) but I saw this mention of my name 😊. Without having
>> read myself into the context there seem to be two issues
>> 
>> 
>>  * Every commit to master should be validate-clean, and this should
>>  be tested by the CI framework not by the contributor. This is
>>  essential. I would be delighted if every commit I made went through
>>  that gate. I’m careful, but occasionally not careful enough.
>> 
>>  * Most – perhaps all – commits should go through a code-review
>>  process. Here I freely admit that I tend to use (or abuse?) my
>>  status to make most of my commits without review, except perhaps
>>  informally with individuals. I’d be absolutely willing to review
>>  this if (a) in fact people think that the extra step would really
>>  improve quality (perhaps looking at past commits) or (b) the very
>>  fact that I do so makes people feel cross.
>> 
> I personally think that we should strive for your first point (every
> commit should be validate-clean) before attempting to tackle your
> second. I, for one, am rather skeptical that putting all of your patches
> through review would significantly affect quality.

I completely agree.

So, what is preventing us from disabling direct pushes to master and requiring all contributions to go through a PR or Differential? 

PRs and Differentials are squashed on merging to master and the whole problem (with CircleCI building only heads of commit groups) just disappears. I believe that this is the usual approach.

If the outstanding issue is that you combine multiple contributions from contributors and manually valid them to ensure they are not just individually sound, but also in combination, we might want to consider

  https://bors.tech <https://bors.tech/>

which is exactly for that kind of thing (and apparently used by Rust).

Cheers,
Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171212/25e48282/attachment.html>