[GHC DevOps Group] State of CI

[Simon Marlow]

I think this reflects a different philosophy about code review. If we say
that code-review is only for small-scale suggestions about the actual code
changes, then yes I'd agree it's not all that useful to keep that history
around. But we can (and sometimes do) have high-level architectural
discussions as part of code review too, and indeed I think it's arguably
the right thing to have these discussion around concrete code proposals. We
keep all the discussion of the code in one place, and the discussion is
attached to the evolving code patches.  In this world, the code discussions
really are valuable history.

Interestingly, I think this discussion has really teased out a key
difference - perhaps the reason people prefer different tools here is
because they're starting from different perspectives about what the tools
are for?  I don't think there's one true way here. Personally I've been
exposed to multiple different working styles, especially having one foot in
industry and one in the open-source world, and I've seen different
philosophies that work.  We could as a project decide that we don't want to
go the way of having high-level discussion alongside code review, in which
case that's OK (I would slightly prefer to move in the other direction, but
that's just my preference).

Cheers
Simon


On 6 June 2018 at 12:58, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> We should keep in mind, though, is that past code reviews is valuable
> content that we can't discard,
>
>
>
> Like Manuel I’m not at all sure about this.
>
>
>
> I **do** regard the Trac conversation as a long-term asset, and often
> refer to tickets from Notes, as a way to say “here’s a more extensive
> discussion of what’s in the Note”.
>
>
>
> But the Phab discussion of “please refactor this or that” seems far less
> valuable.  And actually I don’t think it is substantially cross-referenced
> from elsewhere.  Where there is substantive conversation about the
> approach, I’d rather see that on Trac.
>
>
>
> So for me, long term access to the code-review trail is not very important
>
>
>
> Simon
>
>
>
> *From:* Ghc-devops-group <ghc-devops-group-bounces at haskell.org> *On
> Behalf Of *Manuel M T Chakravarty
> *Sent:* 06 June 2018 12:50
> *To:* Simon Marlow <marlowsd at gmail.com>
> *Cc:* ghc-devops-group at haskell.org
> *Subject:* Re: [GHC DevOps Group] State of CI
>
>
>
> 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.)
>
>
>
> Cheers,
>
> Manuel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20180606/799e0c60/attachment.html>