lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOP-PROP 4: lessons from 2.14


From: Graham Percival
Subject: Re: GOP-PROP 4: lessons from 2.14
Date: Fri, 1 Jul 2011 15:33:32 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jul 01, 2011 at 11:26:04AM -0300, Han-Wen Nienhuys wrote:
> On Thu, Jun 30, 2011 at 1:04 PM, Graham Percival
> <address@hidden> wrote:
> > Catching compilation (make and make doc) errors, and telling us
> > exactly which commits occurred between the last successful build
> > and the current failing attempt, would still save on average 5
> > hours of developer frustration each month.
> > (oh, also running make distcheck)
> >
> > The sooner we know about breakage, the better.
> 
> This was when gub was still in flux, so many compile problems then
> were actually caused by gub changes.

IIRC we have not been able to compile git master 3 times in the
past 2 months.  Normal compile on linux, not GUB.  Just plain old:
  git pull -r
  rm -rf build/
  mkdir build
  cd build/
  ../configure
  make
  make doc
being broken.

Yes, that *shouldn't* happen, but it does.  We've generally
discovered the breakage within 48 hours, but in one case (the pdf
metadata stuff) it took a week.  If we'd known that the pdf thing
broke "make doc" within 24 hours, that would have narrowed the
range of commits to examine -- I remember doing a git bisect to
find where the docs broke (rebuilding from scratch every time!),
because I didn't suspect the pdf stuff at all.

There is no doubt in my mind that such a safety net would save us
developer time and frustration.  Such a script could be easily
dumped into a cronjob; if all is well, it is silent; if any of
those commands fails, it emails a warning to somebody (or a
mailing list) giving the git commits between master and the
previously-working build.

Cheers,
- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]