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

PrevNext  Index
DateWed, 11 Jan 2012 23:02:04 +0100
From Adrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToNedko Arnaudov Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpNedko Arnaudov Re: [Jack-Devel] The Situation(s) With JACK
On 01/11/2012 07:50 PM, Nedko Arnaudov wrote:

> 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.

ACK.

> The jack-common repo itself probably doesnt need git submodules.

ACK.

> 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.

ACK.

[lots about git submodules]
> 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.

So to sum this up, it's either a common subdirectory naming or git
submodules, and you prefer git submodules.

Nothing to argue with that from my point. Anyone else?


Let me try to rephrase the difference:

With git submodules, each implementation can place the header files in
any directory, maybe include/ on jackd1 and headers/ on jackd2.

With direct merges, we have to agree to call it either include/ *OR*
header/.


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

Sounds sane to me. All my names were only placeholders. If nobody
objects, let's call it jack-shared then.


> I'd like to remind once again that jackd1/jackd2 is bad naming for
> repositories.

What do you propose?


Cheers
PrevNext  Index

1326319342.5022_0.ltw:2,a <4F0E06DC.70701 at drcomp dot erfurt dot thur dot de>