On Wed, Dec 11, 2013 at 08:39:58AM +0200, Mike Solomon wrote: > See: > > http://lilypond.1069038.n5.nabble.com/Allows-minimum-length-to-work-for-end-of-line-spanners-issue-7453046-td141952.html#a142870 > as one of several examples. There is truth in anything David says, > meaning that I (like him (and most of us on this list)) have caused bugs > that I did not find or fix before someone else. How, does this warrant > this communication style?
Interesting. I totally agree that lilypond has a problem (see below), but in that email chain I find myself nodding along with David. I mean, he makes empirical claims (such as documentation about partial elliptic stencils) that I assume are accurate (since I doubt he would make empirical claims without checking that they are true). However, I am not blind to the end result of the communications. I mean, at the beginning of September 2012 (after the meeting at the ranch) I was more enthusiastic about LilyPond than I had been for the previous 5 years, but one month later I decided to pretty much quit the project. I know I have the (well-deserved) reputation of being extremely conservative, but that's in part because I don't want to abuse any donations or make any demands on existing/previous volunteers. The idea of providing multiple binaries is one such example (donated web serving and bandwidth), and the general notion of "lilypond should not break stuff that previously deliberately worked" is another. But that's not to say that those constraints are unbreakable. The usual approach in the open-source community to a situation where a significant number of people want to have a radical break with previous traditions is to fork the project. As a thought experiment, let's suppose that a new project forks from 2.18.0, called OakMountain instead of LilyPond. At a bare minimum, OakMountain would need: - a git repository. (trivially easy these days) - does it want to provide binaries? Using GUB would bring in a huge amount of technical constraints, along with a certain amount of bandwidth required. But maybe OakMountain wouldn't care about that; it could target linux only, and provide an Ubuntu disk image for any users on windows or OSX who want to do engraving. (admittedly, the Ubuntu image would also require a fair chunk of bandwidth... but maybe OakMountain would target the default Ubuntu 12.04 live disk image) - does it want to provide any defence against regressions? Maybe not. Maybe OakMountain would guarantee that monophonic music with no lyrics will still work, but anything else could change and break. This is not a rhetorical question. I'm still quite interested in having a music engraving system that's suitable for a "final version" of my string music scores (particularly in conjuction with Vivi, physical modelling performances of those works). As we saw in Sep 2012, LilyPond does not qualify, but if this was a goal of OakMountain then I'd be interested in joining. (that said, I'm contractually forbidden from contributing code to open-source projects until June 2014, although emails and organization are fine) Cheers, - Graham _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
