On Sun, Jan 23, 2011 at 10:29:11AM -0500, Boris Shingarov wrote: > The Lilypond project has a very specific set of objectives. There > is a defined set of procedures, a roadmap, a set of criteria of > what is acceptable to go into the codebase, etc.
This is true of any (well-organized) project. > When these rules contradict Lilypond rules, I > follow the history research project's rules, not the Lilypond > project's rules, because it is the music history research project > that pays me. That is entirely appropriate. :) > What they (and > your Norwegian friends with their 17th century songs) care about, > is whether or not it is possible to typeset Norwegian lyrics. > Which it isn't -- and it's not even Lilypond's fault: SRFI-13 > in Guile does not work with Unicode. eh? We've had utf-8 lyrics for a while. Anyway, that's an aside. > So we have all this work done, but it would be an even bigger > effort to merge it back. This is a general problem with all software projects -- commercial, open source, in-house, world-wide, etc. I've read comments on programming forums or blogs saying that it takes 5 times the effort to merge something upstream than it does to implement it in the first place. There's lots of discussion online about sending linux kernel patches upstream, or gcc patches, etc. > However, I am making aggressive steps to change this. As we > attract more attention from serious organizations, we get into > position to bring forward some conditions for the next project. > Namely, it will become imperative that all contributions get > merged back into the community codebase. Yes. Basically, it's a trade-off. If you work by yourself (or with a small group of programmers), you can do whatever you want. Focus on just the features you want, break other stuff, use shortcuts that could potentially cause problems later on but aren't relevant yet, etc. There's nothing wrong with this -- I work in this manner quite often on my own personal research projects. However, if you work by yourself, then it's more difficult to share your code with other people (if you want to), and you can't get improvements that other people have made (if you care about those). Now, in your case, your group doesn't care about piano music or orchestra stuff. That's totally fine! But what if the guile 2.0 change could speed up your processing? Or maybe your group could benefit from Benko Pal's "black mensural notation and coloratio in white mensural notation" work? Well, the more your source tree diverges from the main lilypond git tree, the harder it will be to get those changes. *shrug* I'm not saying that it's worth trying to merge your patches. That's really a question of how much work you want to do on general maintenance, how long you think your group will be working on this projects (or related future ones), etc etc. In the very long term, I think that merging things with main git will be less work. Once we accept a patch, we'll turn down other patches that break your features, so that aspect of maintenance is now *our* problem (or the next patch submitter's problem), not yours. However, by "very long term", I'm thinking "5-10 years". If you're only doing a 2-year project, with regular deadlines, and don't expect to be doing anything else like this after 2 years, then I honestly think it would be irrational of you to spend time+effort merging patches with main lilypond git. As you know, we're trying to make it easier for contributors, easier to discuss+merge new features, etc., but it's not an easy process If it's not worth merging stuff now, it might still be worth it in 6 months. This is really a question between you and the people who sign your paychecks... another option might be to allocate a short amount of time (say, 2 hours a week?) to spend on merging patches. That way, at least you (and your bosses) know how much time you'll lose on this task. Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
