Proposal: Professionalizing GHC Development

Sun Apr 1 09:09:05 UTC 2018

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 , <amindfv at gmail.com 
> <mailto:amindfv at gmail.com>> 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 <gershomb at gmail.com
>     <mailto:gershomb at gmail.com>> 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
>     > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180401/dac96bc7/attachment.html>