Re: Proposal: Professionalizing GHC Development

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