<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Could you clarify? I see two promising proposals in this:</p>
    <p>A) Redefining proof-of-work to mean one has to compile a GHC
      instead of computing some obscure hashes only nerds care about<br>
      B) GHC will be compiled via contracts in the blockchain, to make
      sure all mistake remain attributable</p>
    <p>I like both ideas, but maybe you had something different in mind?</p>
    <p>Or maybe we can combine both. Nested blockchains. Recursion! I
      wonder if there's a lens for that already…<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 2018-04-01 07:33, David Kraeutmann
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAJ8B99yxqX70cwEPH-r6zYet6GWahKUG1o5L=tztd=TRO1x6YA@mail.gmail.com">
      <div dir="auto"><span
          style="font-family:sans-serif;font-size:12.8px">Leveraging the
          blockchain to compile GHC is a great idea!</span>
        <div dir="auto" style="font-family:sans-serif;font-size:12.8px"><br>
        </div>
        <div dir="auto" style="font-family:sans-serif;font-size:12.8px">Unfortunately
          the proof-of-work algorithm is still just wasted cycles.</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Sun, 1 Apr 2018, 07:28 , <<a
            href="mailto:amindfv@gmail.com" moz-do-not-send="true">amindfv@gmail.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">Overall this
          is a great proposal; glad we're finally modernizing! Still,
          it's got a pretty steep price tag - maybe we can offset costs
          with an I.C.O.? ("GHC Coin"?)<br>
          <br>
          <br>
          > El 1 abr 2018, a las 00:56, Gershom B <<a
            href="mailto:gershomb@gmail.com" target="_blank"
            rel="noreferrer" moz-do-not-send="true">gershomb@gmail.com</a>>
          escribió:<br>
          ><br>
          > Fellow Haskellers,<br>
          ><br>
          > Recently there has been much work into creating a better
          and more<br>
          > professional GHC development process, including in the
          form of DevOps<br>
          > infrastructure, scheduled releases and governance, etc.
          But much<br>
          > remains to be done. There continues to be concern about
          the lack of<br>
          > use of industry-standard tools. For example, GHC
          development is tied<br>
          > to Phabricator, which is a custom product originally
          developed for<br>
          > in-house use by an obscure startup. GHC development is
          documented on a<br>
          > wiki still -- ancient technology, not appropriate for
          2018. Wiki<br>
          > syntax for documentation needs to be replaced by the only
          modern<br>
          > standard -- github flavored markdown. Trac itself is
          ancient<br>
          > technology, dating to 2003, well before anybody knew how
          to program<br>
          > real software. It provides no support for all the most
          important<br>
          > aspects of software development -- Kanban boards, sprint
          management,<br>
          > or even burndown charts.<br>
          ><br>
          > What is necessary is an integrated solution that
          holistically<br>
          > addresses all aspects of development, fostering a DevOps
          culture,<br>
          > embracing cloud-first, agile-first, test-first,
          disrupt-first<br>
          > principles, and with an<br>
          > ironclad SLA. Rather than homegrown solutions, we need a
          GHC<br>
          > development process that utilizes tools and procedures
          already<br>
          > familiar to regular developers. Cross-sectional feature
          comparison<br>
          > analysis yields a clear front-runner -- Visual Studio
          Team Services.<br>
          ><br>
          > VSTS is a recognized Leader in the Gartner Magic Quadrant
          for<br>
          > Enterprise Agile Planning tools. It lets us migrate from
          custom git<br>
          > hosting to a more reliable source control system -- Team
          Foundation<br>
          > Version Control. By enforcing the locking of checked-out
          files, we can<br>
          > prevent the sorts of overlap between different patches
          that occur in<br>
          > the current distributed version management system, and
          coordinate<br>
          > tightly between developers, enabling and fostering
          T-shaped skills.<br>
          > Team Build also lets us migrate from antiquated makefiles
          to modern,<br>
          > industry-standard technology -- XML descriptions of build
          processes<br>
          > that integrate automatically with tracking of PBIs
          (product backlog<br>
          > items), and one-button release management.<br>
          ><br>
          > In terms of documentation, rather than deal with the
          subtleties of<br>
          > different markdown implementations and the confusing
          world of<br>
          > restructured text, we can utilize the full power of Word,
          including<br>
          > SharePoint integration as well as Office 365
          capabilities, and integration<br>
          > with Microsoft Teams, the chat-based workspace for
          collaboration. This<br>
          > enables much more effective cross-team collaboration with
          product and<br>
          > marketing divisions.<br>
          ><br>
          > One of the most exciting features of VSTS is powerful
          extensibility,<br>
          > with APIs offered in both major programming paradigms in
          use today --<br>
          > JVM and .NET. The core organizational principle for full
          application<br>
          > lifecycle management is a single data construct -- the
          "work item"<br>
          > which documentation informs us "represents a thing,"
          which can be<br>
          > anything that "a user can imagine." The power of work
          items comes<br>
          > through their extensible XML representation. Work items
          are combined<br>
          > into a Process Template, with such powerful Process
          Templates<br>
          > available as Agile, Scrum, and CMMI. VSTS will also allow
          us to<br>
          > analyze GHC Developer team performance with an integrated
          reporting<br>
          > data warehouse that uses a cube.<br>
          ><br>
          > Pricing for up to 100 users is $750 a month. Individual
          developers can<br>
          > also purchase subscriptions to Visual Studio Professional
          for $45 a<br>
          > month. I suggest we start directing resources towards a
          transition. I<br>
          > imagine all work to accomplish this could be done within
          a year, and<br>
          > by next April 1, the GHC development process will be
          almost<br>
          > unrecognizable from that today.<br>
          ><br>
          > Regards,<br>
          > Gershom<br>
          > _______________________________________________<br>
          > ghc-devs mailing list<br>
          > <a href="mailto:ghc-devs@haskell.org" target="_blank"
            rel="noreferrer" moz-do-not-send="true">ghc-devs@haskell.org</a><br>
          > <a
            href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
          _______________________________________________<br>
          ghc-devs mailing list<br>
          <a href="mailto:ghc-devs@haskell.org" target="_blank"
            rel="noreferrer" moz-do-not-send="true">ghc-devs@haskell.org</a><br>
          <a
            href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
            rel="noreferrer noreferrer" target="_blank"
            moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>