Could we not configure travis-ci to run the benchmarks for us or something like that? A simple (free) ci setup would be easier than finding a pair of hands to do this regularly I would've thought.
On 30 Nov 2012, at 14:42, Simon Peyton-Jones <simo...@microsoft.com> wrote: > | > While writing a new nofib benchmark today I found myself wondering > | > whether all the nofib benchmarks are run just before each release, > > I think we could do with a GHC Performance Tsar. Especially now that Simon > has changed jobs, we need to try even harder to broaden the base of people > who help with GHC. It would be amazing to have someone who was willing to: > > * Run nofib benchmarks regularly, and publish the results > > * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep > track of regressions > > * Investigate regressions to see where they come from; ideally > propose fixes. > > * Extend nofib to contain more representative programs (as Johan is > currently doing). > > That would help keep us on the straight and narrow. > > Any offers? It could be more than one person. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- > | users-boun...@haskell.org] On Behalf Of Simon Marlow > | Sent: 30 November 2012 12:11 > | To: Johan Tibell > | Cc: glasgow-haskell-users > | Subject: Re: Is the GHC release process documented? > | > | On 30/11/12 03:54, Johan Tibell wrote: > | > While writing a new nofib benchmark today I found myself wondering > | > whether all the nofib benchmarks are run just before each release, > | > which the drove me to go look for a document describing the release > | > process. A quick search didn't turn up anything, so I thought I'd ask > | > instead. Is there a documented GHC release process? Does it include > | > running nofib? If not, may I propose that we do so before each release > | > and compare the result to the previous release*. > | > > | > * This likely means that nofib has to be run for the upcoming release > | > and the prior release each time a release is made, as numbers don't > | > translate well between machines so storing the results somewhere is > | > likely not that useful. > | > | I used to do this on an ad-hoc basis: the nightly builds at MSR spit out > | nofib results that I compared against previous releases. > | > | In practice you want to do this much earlier than just before a release, > | because it can take time to investigate and squash any discrepancies. > | > | On the subject of the release process, I believe Ian has a checklist > | that he keeps promising to put on the wiki (nudge :)). > | > | Cheers, > | Simon > | > | > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
