‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, January 29, 2021 11:44 PM, Fons Adriaensen <f...@linuxaudio.org> 
wrote:

> On Fri, Jan 29, 2021 at 07:59:58PM +0000, John Rigg wrote:
>
> > I don't think the fork was handled very well, with antagonism
> > on both sides which could easily have been avoided with a
> > little forethought.
>
> Indeed.
>
> > The choice of the name New Session Manager and the re-use of
> > the NSM initials is an obvious problem IMO.
>
> I agree. Also presenting this as a consortium project is
> questionable to put it mildly.

I'm glad that I'm not the only one.

I think there are two aspects, one ethical and one practical.

The way they try to take over the NSM landscape, with their deceiving use of 
language and the (mis)use of their community roles, doesn't show any signs of 
respect to the one who actually designed this thing. Nor to it's community who 
worked hard to create this unique linuxaudio session management landscape. Not 
being humble, because you realize you just copied the thing, but didn't design 
it.

Then there is the practical side, where it is obvious that it's not good that 
two teams work on the same session management landscape and on the same API, 
cause they took the freedom to change the API without discourse too.

Personally I did my best to avoid it. I thought I was working with the Agordejo 
developer on a situation where he could work out his new GUI for NSM and having 
nsmd, with one or two extra patches maybe in a dedicated repository, not part 
of Non-Daw and without the NTK dependency. It was even the NON developer who 
suggested something like this.

But in meantime, a small group of 'wise man', including the same Agordejo 
developer, orchestrated by the man with the many roles in this community (but 
who now strangely denies his undeniable role in this fork), where working on a 
huge take-over apparently... They dream big, unrealistically. They thought NSM 
patches would fall from the sky, with their fork.

It proofs to be very hard already to create a modular environment with stable 
JACK tools, working together with one session API. Finally we have that one 
session API, but still, lot's of JACK applications are not stable or don't have 
a NSM patch.

In other words, we don't need a revolution, we don't need big dreams, we need 
small fixes and especially we need to cherish this unique session landscape, 
with one session API. It's better to accept small annoyances, then to try to 
fix them with huge plans, cause you're only creating problems that are far 
larger then the small annoyances. A screwed session landscape.

The last thing is under pressure obviously, with this fork. You see they're 
already changing the API and it's pretty likely they think they will need a big 
API change sooner or later and they won't hesitate to do it, that is what their 
way of forking tells us. They will find that excuse.

It's a sad situation indeed.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Reply via email to