[GHC DevOps Group] CircleCI job accounting question

[Boespflug, Mathieu]

Ben wrote:
> Admittedly this is where a Git-based workflows have a bit of an
> advantage: it is much more convenient to merge a group of commits in a
> structure-preserving manner via a git branch than a stack of
> differentials.

So if both parent commits of a merge commit were guaranteed to build and
test, would that be enough? Or would you still want to insist that all
commits of both branch build and compile? Technically, it's easy to do
(just make the CI script loop through each commit between merge base and
branch tip). But would you be willing to pay for (sometimes substantially)
longer validation times just to guarantee a pristine history?

I think I'm once again confused about what the requirements really are
here, and in what order of preference. Once we know that, I'm confident
many technical solutions could satisfy them.

Note that we can decouple the question of whether to manage contributions
via PR's or otherwise from the review tool question. One could imagine
contributions *always* going through GitHub PR's, but say *always* reviewed
via Phabricator (say via an import/sync tool discussed many times before
but never actually implemented).

--
Mathieu Boespflug
Founder at http://tweag.io.

On 12 December 2017 at 16:54, Ben Gamari <ben at well-typed.com> wrote:

> Manuel M T Chakravarty <manuel.chakravarty at tweag.io> writes:
>
> > Hi Ben,
> >
> >> Am 12.12.2017 um 02:22 schrieb Ben Gamari <ben at well-typed.com>:
> >>
> >> 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.
> >
> On re-reading what I wrote above, I realize that it was a bit unclear.
> To clarify, the sentence
>
> >> I, for one, am rather skeptical that putting all of your patches
> >> through review would significantly affect quality.
>
> was intended to mean "I am not convinced that quality would improve as a
> result of review". Is this what you are agreeing with?
>
>
> > 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.
> >
> We generally don't want to squash. Those who typically commit directly
> generally master generally take pains to ensure that their commit
> history is sensible. This history is valuable, both for the future
> readers of the code as well as later bisection; projecting it out is
> quite undesirable.
>
> We could indeed require that Simon, et al. open Differentials for each
> of their commits. However, as I mentioned earlier it doesn't seem likely
> that putting these commits through rigorous review would be fruitful
> relative to the work it would require; these differential would be just
> be for merging. Unfortunately, the cost of creating a differential is
> non-trivial and I'm not certain that we want to make Simon pay it for
> every commit.
>
> Admittedly this is where a Git-based workflows have a bit of an
> advantage: it is much more convenient to merge a group of commits in a
> structure-preserving manner via a git branch than a stack of
> differentials.
>
> > 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).
>
> Indeed, I'm familiar with bors. Unfortunately it's quite GitHub-centric,
> so at for the moment it's not a viable option.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20171213/8bd72944/attachment-0001.html>