Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/28/2013 02:23 PM, Urs Liska wrote:
> I'm somewhat reluctant to this overhead to keep everything in sync.
> But I have to admit I don't have any practical experience with that.
> And I haven't found a way so far (for myself) to cope with the growing 
> number of repos that have to be kept in sync every day.

git submodule update [--init] doesn't work?

What are the particular sychronization problems that you see arising?

> The dependencies between the parts is there only for contributors, but: 
> Everybody who wants to contribute is responsible to contribute the 
> relevant documentation for the contribution. And to compile the manuals 
> one needs everything: The basic LaTeX stuff, musicexamples, and 
> lilyglyphs. So if I want to contribute, I'd have to clone the repos, 
> have to take care of not breaking anything with the remotes of the 
> submodules. Maybe I'm wrong with that, but it somehow looks scary to me.
> Users who only want to _use_ one or more of the parts will get archived 
> 'releases' anyway.

Let's put it this way: "breaking" dependencies should be only one way, i.e. if
you change the toolbox or lilyglyphs then perhaps the manuals won't work, but
changing the manuals shouldn't _break_ those upstreams.  (They might contain
incorrect or out-of-date information, but that's a slightly different problem.)

Now, in turn, it ought to be possible to organize and plan things so that
breaking changes are rare.  This is effectively a policy issue.

To put this in context, KDE is a huge project with uncountable
inter-dependencies among projects, and which originally was tracked in one
super-huge SVN repo.  But on switching to git, they moved to the
one-submodule-per-package model.

I think you need to think of it like this: users who only want to _use_ one or
more of the parts may operate off archived releases, but what about users who
only want to _work_ on one of the parts?  It's really not clear to me why
someone who wants to work solely on lilyglyphs (say) should have to pull in
OLLib or the manuals.  Likewise it's not clear to me why someone who contributes
something to the toolbox should have to contribute documentation beyond the most
basic description (which is why I suggested drawing a line between the basic
toolbox documentation and more in-depth tutorials and manuals).

It just seems to me that, looking at things, your sense of interdependency
between the parts is a social rather than a technical requirement, and that
tweaking those social requirements could still get you where you want to go,
just making it much technically easier.

LP contribution is in itself unnecessarily complicated because the requirements
for doc and code contributions overlap in a way that they shouldn't have to, and
I don't think you should make the same mistakes.

For example, one of the benefits of DVCS is that it means that I can work on my
little submodule by myself, do what I want to, and only worry about breakages
when I'm submitting for merge -- when it gets run through the test suite.

_That's_ how you keep things in sync, by automated testing prior to accepting a
pull request, rather than by forcing everyone to have the whole massive archive
on their machine and keep it in sync manually (which apart from a few
hyper-virtuous individuals won't happen in any case).

I think GitHub has some nice tools for integrating pull requests with automated
testing, and this could be worth looking into.