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 , 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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs