lilypond-devel
[Top][All Lists]
Advanced

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

Re: Automatically checking regtests (was: Re: Minor releases?)


From: Graham Percival
Subject: Re: Automatically checking regtests (was: Re: Minor releases?)
Date: Sun, 4 Oct 2009 15:55:36 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Aug 17, 2009 at 07:58:32PM -0300, Han-Wen Nienhuys wrote:
> On Mon, Aug 17, 2009 at 7:58 PM, Han-Wen Nienhuys<address@hidden> wrote:
> 
> >> Yes.  All it takes is bookmarking the site, checking it whenever
> >> there's a release, and reporting any broken examples.  However,
> >> nobody is willing to commit to do this.  15 minutes whenever
> >> there's a release, which happens at most once every two weeks.
> >
> > This is the wrong priority:  this is the release manager's task, and
> > in the ideal world, and the RM would continue the release if there are
> > regression errors.
> 
> I mean: he would stop the release process.

Agreed for stable releases, but I disagree for devel stuff.  The
most important part of devel releases is to allow/encourage
development.  If the syntax changes, then nobody[1][2] can do doc
work any more.

Now, in an ideal world, everybody has Linux, has all the build
tools installed, and knows how to use them.  But we don't live in
such a world -- it's a pain to compile lilypond even on OSX.  (I
used OSX for 4 years, and I can't recall *ever* compiling lilypond
on it!)


[1] ok, *I'm* obsessive enough to work on docs that I can't
compile, and foolhardy enough to commit doc changes I haven't
tested -- but few people will do the first, and nobody should do
the second.

[2] most of the more technically-inclined doc writers have shifted
focus to programming.  I heartily encourage this, since we need
more programmers, but it *does* mean that our "average" doc
writer... whatever that term might mean... is unable to compile
lilypond himself.


Therefore, if I think there's a need for a new binary (syntax
change, major new feature, etc), then as long as the installers
and docs compile, we should have the unstable release.

Users will just have to learn that "unstable release" means
"unstable".  :)

Cheers,
- Graham




reply via email to

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