On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote:
On Sun, Apr 18, 2010 at 5:16 AM, rosea.grammostola
<rosea.grammostola(a)gmail.com> wrote:
It's pretty odd that you guys didn't
discuss this clearly with each
other. It seems that people have an opinion about something, but only
share this with people who have the same opinion and not with the one
who himself or his code is subject of 'critique'. This is bad
communication and bad team management.
oh god. you clearly don't understand ANYTHING about how open source
development works.
there was constant discussion about all of this. But Stephane doesn't
own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn
doesn't own JACK. When someone works on their own implementation of
JACK, they are free to make their own decisions about how things are
done. Maybe their ideas will be better (or worse, or about the same)
as any existing implementation, and because of this, its important to
allow them to take shape as they see fit. Clearly, providing useful
feedback and ideas is great, but there's no reason for any committees
or meetings to decide how a different implementation is going to work.
In this particular case, Jack2 started out (as Stephane has described)
as a sort of experiment - how would SMP support work, could we do
click-free graph changes, would a C++ implementation be easier to
manage, etc. etc. In that context, its not appropriate for anyone
who's not actually working on it to be trying to make decisions about
internal design. Lots of people, including myself, had input into the
design and evolution of Jack2. Pretending otherwise is ridiculous.
Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83%
of the same API. Beyond that, how they work internally is the business
of their implementors and maintainers. If someone has an opinion about
it, they are free to take it up with the implementors and maintainers.
If they feel strongly enough about it, and they don't feel that the
implementors/maintainers are doing things in the right way, they can
fork or reimplement (this clearly doesn't happen much).
This could all be true, but that's not the point I was talking about.
JACK2 was planned as successor of JACK1. But at some point that changed,
that's all ok, not the point here. But isn't it odd that this isn't
clearly communicated with the JACK2 maintainer, why this is happened?
That was raising questions here about the communication within the
(highly appreciated) JACK project.
quote=Stephane
I must say that I still don't have a clear
understanding of why this
happened. I still don't understand the sentence "Like Torben, there
are some design decisions there that I have questions about." and I
think explaining it in more details would really help.
Regards,
\r
It would be good if an '(mini) JACK
Conference' will be organized, where
JACK developers can speak each other face to face, code to code. And
share future vision, coding vision etc. IRC and mailinglists are great,
but not always the good method for communication.
Traditionally, this would be done at the Linux Audio Conference, which
I will, alas, be unable to attend this year. That doesn't stop other
people from meeting on these issues, but my impression is that we have
all become somewhat tired of struggling with the situation and instead
have been trying to find ways to allow the status quo to continue, but
better.