On Wed, Jul 11, 2012 at 05:48:48PM +0200, Janek Warchoł wrote: > On Tue, Jun 26, 2012 at 10:55 PM, Graham Percival > <gra...@percival-music.ca> wrote: > > To avoid slowing down programming to a crawl, I figure that we’ll > > identify some subset of these regtests and have a separate make > > regtests-quick command which only evaluates that subset. > > > > As a rule of thumb, I’d say that the regtests-quick target should > > take as long as a make from scratch. > > *very* good idea! +20
Well, there's no reason why this needs to be tied to a specific release policy. There's certainly no harm in implementing the basic infrastructure of "make regtests-quick", leaving any debate about exacty which files qualify for the "quick" test. Problem is, somebody needs to sit down and do it. Do you feel like adding that? > We could actually adopt a policy of aiming to have a stable > release each 3 months, which should help with that. I definitely think we should have stable releases much faster, although I'd target 3-4 rather than simply every 3 months. But that won't happen until/unless the regression tests have much better coverage. This problem breaks down to: - 10-20 hours of build system work. (to add the regtests-quick target) - 10-100 (?) hours of programmers to investigate+discuss code paths (?) - 10-100 (?) hours of helpful users organizing and writing .ly files to cover all (? or most?) functionality - possibly 10-20 hours of python programming to extend Patchy and/or the Paris university server - somebody to organize the entire effort I'm sadly not volunteering for any of those tasks. I'm happy to organize policy discussions about what to do with the results of those tests (specifically for the 2.18 or 3.0 or other releases), but I think we need some real effort on the fundamental infrastructure before it makes sense to have policy discussions on this. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
