2012/1/3 Graham Percival <gra...@percival-music.ca>: > It so happens that none of these Critical issues are really > fixable by reverting a single commit. > > [...]
ok, thanks for this explanation! >> 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. Silly me, i forgot about that. 2012/1/3 David Kastrup <d...@gnu.org>: > The Learning Guide and the Notation Guide need a complete rereading and > reorganization, and it is not like the Extending Guide is in > significantly better shape. I'd like to fix them too, but i don't have time for everything i want :( Splitting my time doesn't look like a good idea - it's more effective when i put all my foxus on one thing, analyze it deeply and make a complete solution than swap issues. I have to choose and i choose improving graphical output. >> I can even imagine that well announced release candidates for a new >> stable version attracts developers to help fix issues with problematic >> platforms. > > If you take a look at Ubuntu release candidates, they usually start with > a list of "caveats" concerning computers and applications that won't run > at all. You need to _start_ with the work for cutting out a release > before it is magically finished. Indeed this looks like a good point. Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
