[GHC DevOps Group] State of CI

[Moritz Angermann]

While we are discussing code review, I found what jane street demoed here
quite interesting: https://www.youtube.com/watch?v=MUqvXHEjmus

From the Code Reviews I've done/seen in Phabricator, I'm inclined to say
that I've rarely went back to look through the review history. Unless it
was one of my Diffs, and I had forgotten what it was all about in the
mean time.

Cheers,
 Moritz

> On Jun 6, 2018, at 8:08 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> On 6 June 2018 at 12:49, Manuel M T Chakravarty <manuel.chakravarty at tweag.io> wrote:
>> Am 06.06.2018 um 19:11 schrieb Simon Marlow <marlowsd at gmail.com>:
>> 
>> * None of this work is GitHub specific. Nor all that CircleCI or
>> Appveyor specific for that matter (work is currently focused on
>> improving the test suite).
>> * Our GitHub lock-in factor is currently low to pretty much absent,
>> and would remain low even if the review workflow becomes more
>> systematically GitHub centric (it already is for some small
>> contributions).
>> * That's because tickets remain on Trac, and the code along with the
>> entirety of its history remains in a standard Git repository, GitHub
>> or not. Also because GitHub is not a CI provider, those providers we
>> do use integrate with other code hosting solutions (e.g. Appveyor with
>> GitLab), and the surface area of CI provider-specific code is small.
>> 
>> We should keep in mind, though, is that past code reviews is valuable content that we can't discard, nor can we easily migrate it to a different code review platform. At this point we have nearly 5K diffs on Phabricator, many of which have non-trivial code-review trails, and these are cross-referenced from Trac, emails, and other places. Even if we moved to github, we would want to keep Phabricator running so that we have access to this content, and people will experience friction though havng to deal with another system.
>> 
>> To me, the friction caused by the transition and the inability to do a clean move is more worrying than the missing code review functionality on github.
> 
> Actually, to me this is a red flag. Core reviews shouldn’t be essential documentation. I wonder what has been going wrong so that we have got to this situation.
> 
> If important points are uncovered or documented in code reviews, that information should be included in either the source code or associated documentation. (Having git history as an important record for the evolution of the code is fine as it is now standard to not only have one snapshot of the source, but a source control history of the source as the definitive record of a piece of software. And as we painfully discover, much in contrast to code reviews, the source control history is recorded in a widely understood standard format.)
> 
> In an ideal world all the history you need is in the repository, but in practice often the extra context of the code review is useful in understanding how things got to be the way they are. We could require people to be meticulous about trying to anticipate which parts of the discussion will be useful and copying those into the commit log, but in practice this isn't going to happen. Code reviews - just like mailing list archives and the discussion on old tickets - is useful history and we need to keep it.
> 
> Cheers
> Simon
> 
> 
> 
> Cheers,
> Manuel
> 
> 
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20180606/7da0bcac/attachment.sig>