Re: critical issues

[Graham Percival]

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