On Tue, Jan 03, 2012 at 06:24:19AM +0100, Janek Warchoł wrote: > By the way, do we have a policy about regressions?
Yes, they're bad? :) > I remember that > reverting bad commits was discussed in the past, and i'm quite for > this solution. > I don't see information about which commits caused our currently open > critical regression, does it mean that's impossible to tell or simply > noone tried to find them? It so happens that none of these Critical issues are really fixable by reverting a single commit. - lilypond-book came from a general rewrite of lilypond-book. - osx came from me accepting a GUB patch which had a problem, which technically we could revert but it's better to just solve the underlying problem. (and in fact I think it *has* been solved) - windows path isn't strictly a regression, but IMO it screws up users' systems in a sufficiently stupid and embarrassing way that I'm going to call it Critical anyway. - git branches comes from staging, which is necessary because people kept on breaking git master. - web-git came from a cleanup of the old website, originating from a build system patch of mine, but come on folks, we already have a patch for this in the system, don't complain about that issue. > Is finding them an easy (no knowledge > needed, a complete set of dumbed-down instructions can be given) task > that can be done using a moderately fast computer running lilydev (1,5 > GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if > multicore thingy translates to virtual machine)? when the problem *is* in the lilypond code base, yes it's brain-dead easy to identify the problematic commit. Instructions are already in the CG -- look in the "regressions" chapter. Cheers ,- Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
