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