Proposal: Professionalizing GHC Development

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Professionalizing GHC Development

Gershom Bazerman
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Professionalizing GHC Development

amindfv
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Professionalizing GHC Development

David Kraeutmann
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 , <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Professionalizing GHC Development

Shao, Cheng
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 <[hidden email]> 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 , <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Professionalizing GHC Development

MarLinn
In reply to this post by David Kraeutmann

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 , <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs