On Mon, 2009-04-13 at 09:45 +0200, David Henningsson wrote: > Done. Anything else I should know when it comes to comitting patches? >
I don't think we should be too hesitant about committing changes, or at least not afraid to. Communication is a good thing and tracking things with tickets in Trac is also very good. We'll likely get a better idea of guidelines as we go along. I think it is better to be actively working on things than to get too caught up in some bureaucratic processes. If someone breaks something, we can bitch at them afterwards ;) When we get closer to our next release though, it would be good to slow things down into some sort of feature freeze state. > >> I have also started to work on getting the new 1.0.9 version into Debian > >> - it was abandoned, so I intend to become the new Debian maintainer for > >> FluidSynth. It's my first official package so I might have some related > >> questions for you as well as the Debian mentors. > > That is great, I didn't realize that the Debian package had been > > abandoned. I guess there has been so few releases in the past few > > years. Its nice that that is changing. > > I've already run into trouble with the debian package, interested people > can have a look here: > > http://lists.debian.org/debian-mentors/2009/04/msg00244.html > > Btw, do you know any other GPL code we (optionally) link to, more than > lash/ladcca? I hadn't even considered the issue with GPL versus LGPL. What a mess. The end of the configure.ac lists other optional packages. Looking at the list, it seems readline is also GPL. I admit being confused now though, since on the readline page it mentions it is GPL but that you can use it with "GPL Compatible" licenses. http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses So not sure what that is all about. Hmm, it just occurred to me. It is one thing to have your program link with a GPL library and its another to have it in turn link with other programs, perhaps that is the distinction? Does anyone use LASH? I would miss the readline support, that is for sure. > > Since there are a number of individuals who have recently become > > interested in FluidSynth development, I think it would be a good idea to > > introduce ourselves a bit and mention what interest we have in > > FluidSynth and how we would like to help out. I'll post a new email > > thread to this effect, to get things started. > > Seems like a very good idea. I could also have use for some pointers to > why it was decided to fork the project into an 2.x branch. > This was suggested by Bernat Arlandis i Mañó and I seconded the idea, or it could be said that I had also thought branching it would be a good idea. Its not a fork, its a branch. The main reasoning was to port FluidSynth to glib and potentially clean up the API. I realize now though, that porting to glib doesn't necessarily require cleaning up the API, the could be thought of as a separate task. Currently FluidSynth has a lot of convoluted code for different platforms. Using glib would clean a lot of this up. It could be something added to the 1.1.0 branch though. It would be good to get an overview of the different features and directions for FluidSynth and start to decide what should be a part of the next 1.1.0 release. It would be nice to release more often and therefore we should perhaps stick with a smaller set of changes. This was why it was deemed a good idea to start a branch. > > // David > Best regards, Josh _______________________________________________ fluid-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/fluid-dev
