Re: critical issues

[Janek Warchoł]

2012/1/3 Graham Percival <address@hidden>:
> 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 <address@hidden>:
> 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