"Boris Shingarov" <b...@shingarov.com> writes: > I am working on a system of markups which allows to specify more > flexible formatting rules. WE are using it for things like multi-line > embedded scores, mixing them with markup lines, rules about what > things / combinations of things should not start / end a line, also > there are rules like "no line break between certain words and > beginning ebmbedded score", that kind of formatting rules. I had > described some of these ideas in my earlier posts on this list. > Markup functions being able to return a list of stencils.
Markup lists don't do the trick here? > Much more importantly, markups need to be aware of what was placed > before, and what is to follow, therefore when processing the > markup-list, we need to pass a continuation at each step, instead of > iterating over the list. This kind of ideas. It even sort of > works. Well, works enough for production use by non-programmer > users. But still far from being a general Lilypond improvement. The > other, easier improvements (orphan-avoiding functionality, > page-breaking fixes), are making it fine into the upstream repo: for > those, going from the happy state of having the user's problem fixed, > to the happier state of fixing it for everyone, is of a reasonable > proportion compared to the whole amount of work. But with my markup > changes, it's much different. Even the first and simplest of these > changes (patch 207105), to go from the current state to an actual > submittable patch, will take like 2x the time it took to get it to > solve the user's probem. I don't see that you stand a chance with the standard processes here. You don't have commit access. The gold standard here (to the exclusion of all other workflows) is a patch review on Rietveld. That basically limits feedback to persons with a Google developer account. At the point of acceptance, the change is pulled in as a single commit touching lots of areas simultanously. Since mainline development continues, there is no sensible strategy for merging/rebasing for anybody without a branch history. So the only person able to work on this will be yourself. People will be able to check your work only when the patch set applies. But that means that mainline changes in the same areas need to be tracked by you and will also pollute the Rietveld review area. I don't see that a task like this can be sensibly done except in a separate branch. But working like that is a git workflow rather than a Subversion one, and does not fit with the Rietveld processes. Of course you can set up your own Lilypond repository for pulling, but the way I see it, the relevant developers would refuse to participate in "non-standard" processes like that. I don't see that humongous changes like that can be usefully integrated in a single non-merge commit. There must be infrastructure changes and so on, and you'll need to set up reviews for each of them, without an apparent goal being accomplished before the last commits make it. 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'd like to see me proven wrong. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
