Proposal: Professionalizing GHC Development

Shao, Cheng cheng.shao at tweag.io
Sun Apr 1 07:10:22 UTC 2018


Compiling GHC on a blockchain may not be economical, but running
GHC-compiled programs on a blockchain is definitely a great idea! I've even
come up with a paper title: A Secure Decentralized Transactional
Implementation of Spinless Tagless G-machine, aka Haskoin!

Time to recruiting a few engineers, write a white paper and raise a seed
round :)

On Sun, Apr 1, 2018 at 1:33 PM, David Kraeutmann <kane at kane.cx> 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> 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> 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
>> > 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
>>
>
> _______________________________________________
> 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/a2555075/attachment.html>


More information about the ghc-devs mailing list