Re: [Jack-Devel] The Situation(s) With JACK

Paul Davis <[hidden]> writes:

> so, moving along, it seems that the first steps (very tiny baby steps)
> to resolving all this stuff involve finding a way to make the header
> files and common example and utility clients shareable by any
> implementation. the obvious solution to this involves putting them
> into a repository in some special way, or putting them in a special
> repository.
>
> i've looked at git submodules and they seem roughly OK for this task,
> but also to have some complications and potential risks. i don't even
> begin to claim to know enough about git or svn or SCM systems in
> general to identify the best way to go about doing this, but i have a
> feeling that someone else on this list does.

Please share the complications and potential risks that are associated
with use of git submodules for this task.

Adrian Knoth <[hidden]> writes:

> On 01/11/2012 01:42 PM, Paul Davis wrote:
>
>> so please comment: what is the best way to put the header files that
>> define the JACK API, along with the source code for the
>> example+utility clients somewhere that any implementation of the API
>> could use them?
>
> I'm also not a big fan of submodules. How about the following:
>
>
>    jack-common --> independent repo
>      + headers --> branch in jack-common with the header files
>      + tools
>      + example-clients
>      + manpages
>
> The last three are also branches of the jack-common repo.
>
> The real jackd repositories:
>
>    jackd1   --> independent repo
>    jackd2   --> independent repo
>
> It doesn't really matter if it's one repo with two branches or two
> repos, but I guess the latter is more convenient to use. Correct me if
> I'm wrong.

git submodules are about how jack-common branches appear in the jack1
and jack2 repos. Whether submodules are used or not is up to the jack
implementator.

The jack-common repo itself probably doesnt need git submodules. But I
agree that having one branch per part (headers, tools, etc) is good
idea. Using single repo makes sense because it can be associated with
single policy.

According to the documentation git submodules can be used with a single
jack-common repo and multiple branches (headers, tools, etc) by
supplying the -b parameter to "git submodule add" command.

Alternative to git submodules are direct merges. This somewhat implies
that the common/shared branch already has appropriate directory
structure. I.e. paths of shared files should not collide with the paths
of non-shared files. We can make sure that it does not collide with
existing implementations (jack1, jack2, tschack) but its still more
restrictive than the submodules approach. Even in case of collisions,
jack implementators can handle it but it could be more work for them
because directory moves may be involved. Directory moves between
branches are possible but tedious to merge.

If we don't put different parts in subdirs, i.e. the headers branch does
not have headers/ subdir, then those who want to use direct merges will
face the tedious rename work on each sync. This situation is probably
best for those who will use git submodule to import the shared stuff.

If we put different parts into subdirs, those who want to use direct
merges still risk to face tedious rename work on each sync but the risk
is smaller than in previous case because they can do the smarter thing
and adjust their own implementation not to conflict. This situation is
not perfect for those who choose to use git submodules either. They will
have additional subdir for each subdir. I.e. something like
shared-headers/headers and shared-tools/tools. This can face stylistic
feelings and force those that have them strong to do the tedious
directory move work on each sync.

jack-common is not that good because jack2 already has common/
subdir. To reduce possibel confusion, I propose to use jack-shared
instead.

So the root question here is what sync strategy jack-shared will
favour. I personally prefer git submodules but If we have one subdir per
part then direct merges will be better. git submodules are safer unless
there is applicable guarantee that jack-shared subdir strategy will
never change.

Having top-level stuff shared/used by different parts (in sybdirs) in
the root directory, e.g. build system, greatly increases chance of path
collisions and thus adds value to the git-submodule approach.

I'd like to remind once again that jackd1/jackd2 is bad naming for
repositories. Not only because of jackdbus in jack2 but also because
jack1 and jack2 contain libjack as well. jackd is not "jack" its a/the
jack server [binary] executable. The jack system has several parts,
headers, client library, server library, jackd server, jackd.py (jack1),
jackdbus (jack2), documentation, etc. Spreading the myth about jackd
being "the whole jack" only promotes ignorance that quite often leads to
confusion.

Its like jackdmp vs jackmp. I guess we can learn from history... Can we?
...Still my guitar gently weeps...

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

1326307909.24671_0.ltw:2,Sa <87ipkiul94.fsf at arnaudov dot name>