"Boris Shingarov" <b...@shingarov.com> writes: > On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: > "Boris Shingarov" <b...@shingarov.com> writes: >> > Markup functions being able to return a list of stencils. > > > > Markup lists don't do the trick here? > > No; if you look at patch 207105, you'll see what I mean. >> I don't see that you stand a chance with the standard processes >> here. > [...] > > Basically you'll be on your own going against the tide until you are > > finished. The work flows here are designed to achieve code quality by > > making it harder for a would-be contributor to get sub-par code through, > > not by making others participate with the work. > > I guess even that assessment is overly optimistic. > The real problem here is not of process, but of fundamental > interests. I am scratching *my* itch, which is, make > top-publication-grade work possible with Lilypond.
If you take a look at Lilypond documentation at the web page, you'll see that this focus is supposed to be a major goal of Lilypond. So that should not be an impediment. > Lilypond did not reach this grade before. So this work is beneficial > to the Lilypond community in two ways: proving we can go on that > territory, as well as purely technical contributions. Now, with > technical contributions that are easy enough to integrate back > upstream, ok I can spend the extra 30% effort to integrate; but 500% > does not seem justifiable The main problem I see with Lilypond is that its development processes are falling apart due to the high complexity it has gained through the mixture of flex/bison/C++/Scheme/PostScript and the consequence that very few people are knowledgable with all of its parts and interoperations (in particular the details of tying together contexts, translators and interfaces, hidden deep in the bowels of C++). And those that are, are busy. Catering for your requirements without bogging separate material on in inconsistent and intractable ways is going to take deep surgery. The resulting code needs to be tied in as well as if it was originally designed in that manner, or nobody will be able to learn dealing with it in sensible amounts of time. You see the current state of page breaking: the appearance is that not more than one person, possibly less, understands it fully at the current point of time. Or at least can be bothered about looking at it. > But I am open to any suggestion how to make it more useful to the > community. The code alone will not be useful would be my guess. It sounds like it might be viewed like a proverbial Trojan horse where tearing down the walls to let it in will weaken the project's defenses against unmaintainability. My personal advice to you is to consider it and treat and value it like a proof of concept: it shows that something _can_ be done to address your problem space. Even by a single person that is not a core developer. A proof of concept is a whole lot better than nothing in your hands. Presenting its design and results achieved with it will be a good step forward to make others move with you. Trying to make the proof of concept code changes as self-contained as possible so that people have less work understanding what you are doing will also help for getting others interested and to understand, even though the end product is desired to be well-integrated into the overall design. That's my take on it, but of course you are aware of my standing here. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
