[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-devel
Subject:    Re: GOP-PROP 4: lessons from 2.14
From:       Graham Percival <graham () percival-music ! ca>
Date:       2011-06-30 16:53:48
Message-ID: 20110630165348.GA29384 () gperciva-desktop
[Download RAW message or body]

On Thu, Jun 30, 2011 at 05:33:08PM +0100, Phil Holmes wrote:
> ----- Original Message ----- From: "Graham Percival"
> <graham@percival-music.ca>
> To: <hanwen@xs4all.nl>
> 
> >Cool project, but I don't think our limitation is processing
> >power.  My desktop is idle at least 95% of the time, so I could
> >dedicate a lot more horsepower to GUB if necessary, and the
> >problem with regtest checking is one of organization: managing
> >volunteers to look at the output.
> 
> For a standard "make" from scratch, the limitation is almost
> certainly processing power.  On my (single core) Ubuntu, by far the
> slowest activity is getting lilybook to generate all the snippets,
> and this is completely CPU bound.

By "our limitation", I'm referring to the lifetime of a patch.
- patch gets written
- patch is put on Rietveld.
- ** James does the regtest comparison with his shiny new 4-core
  8gb-ram machine
- if no regtest errors, patch is tagged with patch-review, waits
  2-6 days (estimated) to appear on patch countdown
- 48-hour patch countdown
- if no (serious) error, patch is pushed.

I don't think that James' regtest comparison is a big problem.
Granted, we'd like developers to run regtest comparisons before
even uploading something to Rietveld, but I still think that the
amount of time this takes (running in the background, right?) is
not very significant when compared to the time it takes to write
the patch in the first place.

Cheers,
- Graham


[prev in list] [next in list] [prev in thread] [next in thread]