Werner LEMBERG <w...@gnu.org> writes: >> I am not sure whether the q stuff should be slated for 2.16. It >> greatly simplifies things and decreases potential for problems, but >> I don't see people reporting any test results, and it certainly has >> seen less user contact than my totally new code. > > As soon it is in master, I'll check it. Sorry for not having enough > time to do it earlier.
Its patch is now respective to master (just advanced master after patchy finally completed the tests and barfed out because the Ethernet slipped, but not before having completed all testing). So to let patchy loose on it with the current master, I'll reset its patch status to patch new (though it is obvious that the last patchy failure was again something because of outdated files -- no idea how they get into Graham's system, or whether updates fail there; I'll start the "small" patchy here for comparison next). But since we don't cut a release branch AFAICS, it is quite pointless to check it "as soon as it is in master". That will be the case when the decision has been made already. While it is conceivable that a commit can be reverted when things go awfully bad, it would be good to make the decision before that. So check it out at least once it is in Patch-review orderly. That means that it is regtest-clean, but that does not mean that a feature change will make its main users happy. And I might point out that it was you who _repeatedly_ pressed for q getting fixed because of its importance to you, even if it meant a solution expensive in developer and possibly execution time. When you now can't be even bothered looking at it, I will think thrice before tackling anything which you call important. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
