Re: GOP-PROP 4: lessons from 2.14

[address@hidden]

On Jun 30, 2011, at 4:17 PM, Han-Wen Nienhuys wrote:

> On Wed, Jun 29, 2011 at 7:26 PM, Graham Percival
> <address@hidden> wrote:
>> http://lilypond.org/~graham/gop/gop_4.html
>> 
>> ** Proposal summary
>> 
>> What went well, what went badly? This is a discussion only; it
>> will be summarized, and we will refer back to it in future policy
>> decisions, but no new policies will be decided in this round.
>> 
>> We’ll have (at least) two sections: one for facts that anybody
>> considers relevant, and one for thoughts and commentary.
>> 
> 
> Overall, I think this cycle took too long.
> 
> We should strive to have policies that make each development release
> be a worthy stable candidate. That means -for example- being serious
> about
> 
> * changes passing through the regtest
> * bugfixes and features always having a test to check against

I agree, and I'd go further to add that one of the problems with the 2.13 
process towards the end was a difficulty in anticipating what to make regtests 
look like so that they tested all possible contingencies.  In order to make 
sure that the regtests are robust w/o forcing each change to go through 5 hours 
of regression testing, I propose that before each minor release, a large 
regression test is run on a suite of real-life pieces followed by a pixel 
comparison.  This'd take a while, but it'd provide a periodic check to nip 
problems in the bud.

Cheers,
MS