Re: [oll-user] Call for initial feedback

[Urs L. <ul...@op...>]

Am 28.03.2013 15:27, schrieb Joseph Rushton Wakeling:
> 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?
I didn't find this in http://git-scm.com/book/en/Git-Tools-Submodules.
The man page for git-submodule states that command, but I have to admit 
that I don't fully understand it.
But that man page also says: "Submodules allow foreign repositories to 
be embedded within a dedicated subdirectory of the source tree". That's 
what I don't really understand in our context: Both documents suggest to 
use submodules to integrate existing remote secondary repositories in 
the main one.
Why this overhead of having a remote repository and its submodule 'mirror'?
And the caveats I read about in the progit book don't look reassuring 
either.
>
> What are the particular sychronization problems that you see arising?
Not really problems, its rather the complexity of the amount of repos.
An example: If I work on, say, the manual for 'musicexamples' I may run 
into updating the stylesheet package. If everything is in one repository 
I will surely notice the need for committing this change, at least if I 
want to power down the computer and see that git status isn't clean.
If the files were in separate repositories I would have to take care 
myself that I don't forget to update also the repo with the stylesheet in.
Or: Each time I have to change a computer I have to go through all the 
repos to check if there are changes to be fetched and merged (or 
rebased). That's quite tedious and requires a fair amount of 
concentration in order not to omit a branch, for example.
>
>> 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.)
That's right (and also the case currently)
>
> 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.
Maybe you're right. But: As it is now I have to tell the contributor: 
"clone the repository and make sure that LaTeX finds this folder and 
LilyPond finds this folder. You may have stuff there that you don't 
need, but you get everything you need with one clone." If there were 
smaller chunks I'd have to say: "You may clone the module you want to 
work on, but you will have to download and install the musicexamples and 
lilyglyphs packages in order to compile the docs.
> 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).
I will have to think about that, but I'll also comment on your other 
email about that.
> 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.
OK, but I'll have to come back later to this, as it seems somewhat too 
much right now ;-)

Best
Urs
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user