Hi,thank you all for your helpful and diverse input! I also agree with most of what has been said. Even though I do have time to contribute to LMMS I do not have the time for being the only primary developer, which has been a severe problem in the past. It's true that the Git repositories on Sourceforge are not very visible and thus it's hard to attract new developers, so I'd prefer the Github solution as well. To make an immediate start, I just created a development space on github.com/lmms with a repository at github.com/lmms/lmms (currently uploading branches). Hopefully this will ease collaborative development alot and allow easy management of pull requests. I'm willing to continue managing development on Github however I'd vote for choosing someone else as project manager who does not only coordinate development but all the aspects that were mentioned in this thread.Nevertheless this will not solve problems with patches which we simply can't accept due to the code quality. I know that much of the historically grown code is a mess too, but many patches in the past did not even meet basic coding style guidelines (http://lmms.sourceforge.net/wiki/index.php/Guidelines_on_coding_style) and often the visual integration into the existing UI has not been satisfying. So what we definitely need is a team of UI designers!Another oberservation I recently made: rolling-releases are the only way to go. When we started the stable 0.4 series we branched off the master branch and basically overloaded it with new features and massive changes leading to a completely diverged source code base. Thus bug fixes to the stable-0.4 series began to be lost in the master branch. Today the master branch is a mess and IMHO it's not suitable for stabilization anymore. I therefore recently started to pick all the goodies from it and backport it to different branches based on the 0.4 series (done so far: improved undo/redo support, new FX mixer with sends etc.). This way we can stabilize features individually and merge them little by little into continuous releases. For the next release it's probably a good idea to stabilize what has been integrated recently. The release afterwards should integrate the improved undo/redo support, the new logo (I think proposal 2 in the discussion one year ago got the most votes) and maybe already the new FX mixer. I also like the proposal to rename SongEditor to Sequencer and B+B-Editor to "Pattern Editor". We need terminology consistency in other places as well (e.g. "tacts" -> "bars").What I'm planning to backport in the future (as it once has been developed by me):- new settings dialog- Resources framework for locality-independent usage of resources (audio files, project files, presets, ...)- welcome screen- new ProjectRendererTo be taken care of soon:- new UI concepts for abandoning most of the MDI stuff by making central components have a fixed place with easy collapsing possibilitiesAbout communication: for development purposes, I still prefer mailing lists over forums or similiar as management of messages etc. is much easier. As soon as the new development on Github is gaining momentum, certainly much of the communication will happen on this platform directly.As for the name I'd stick with LMMS as well but get rid of "Linux MultiMedia Studio". However I'd leave a final decision up to a new project manager and/or an extensive survey.One more thought: IMHO we never claimed LMMS to be a real professional DAW. We aim at hobby and semi-professional users. We surely can satisfy their needs if LMMS development gains new momentum this year.So far..Toby
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
LMMS-devel mailing list