<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>