[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Soundfont banks

From: Ebrahim Mayat
Subject: Re: [fluid-dev] Soundfont banks
Date: Wed, 11 Jul 2012 17:07:57 +0000 (GMT)

On Jul 11, 2012, at 08:41 AM, Matt Giuca <address@hidden> wrote:

I really don't want to fuel the fire here, but I'd just like to speak with some experience on both sides of the patch/pull game.

You and Pedro seem to stick with only what you prefer with the Soundfont specs and GS-specs, both of which only deal with 128 soundbanks.

I've been observing this conversation, and while I do think the reaction to the original mail (on a completely different topic by a different contributor) was overly negative, there also has to be room in a software project to say "no."

My understanding of the project is that there aren't a lot of people contributing, nor do the people at the top have much time to give. Therefore, proposing drastic changes is probably not going to be feasible, even if it's theoretically a good idea.

Hello Matt

The OP for the previous thread was clearly willing to work in a step-by-step manner so the problem was not really a question of patching drastic changes. 

It's more complicated than saying to the project leads "I don't expect you to deal with this, I'll do the research and the work." The problem is that ultimately, someone who "owns" the project will need to understand this stuff in order to accept it. They will need to review your patch and understand how it fits in with the overall system and the interests of many users. For example, whether including this patch will break other users in some obscure case, or whether it will pull in too many dependencies. If you are proposing a non-trivial amount of work for yourself to do, it will ultimately end up becoming a non-trivial amount of work for someone else as well.

There's also the fact that if you submit it, you may not be around to maintain it, and then people like David will have to understand it even better to fix it when it breaks.

I'm not trying to be a nay-sayer and block progress. I just want to make the point that sometimes, as a project lead, it isn't a good idea to embark on a large new feature with a contributor you don't know well, especially if you don't have much time to give to the project yourself.
The sad thing is that the project may have lost an extremely talented potential contributor all because of resolute resistance not consistent with fact. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]