Excerpts from Philipp's message of 2010-06-05 13:18:02 +0200: > Hi, > this is all about making Linux Audio more useful. > The idea came about because on the one hand there are parts of Linux > audio that really need some coders attention and on the other hand there > are coders who don't know where to start. I realize that there never are > more than enough coders, so this is mainly about bringing attention to > the parts that need it the most. > > To a degree it's what bug/feature trackers are there for, but those are > usually per application, and while there are category and priority > systems in place those are rarely used. > So what this is also about is bridging a gap between users, developers > and between applications. > > It would be quite simple really. > An easy to find, central place, possibly a wiki or a tracker. > Anyone, a user most likely, describes his workflow and what the > showstopper is. This could be applications not syncing properly, or an > essential but missing feature. The idea is to tackle mainly > infrastructure and cross application problems, with the goal to make a > workflow actually work. > The user should have to specify all relevant information available, such > as version information, links, probably some kind of priority or urgency > indication and how hard he believes it would be. > He could also put up a reward of sorts, not necessarily monetary. > Any developer could pick up the task and work on it, possibly leaving a > notice. > > The possible benefits I see are: > a) A kind of overview of what's needed the most, one place where you can > see what's actually important to users. > b) A way to identify and fix problems between applications - something I > believe is very important for a system that encourages the use of > multiple applications at once. I believe there are numerous > synchronisation/transport issues for example which are never really tackled, > despite this being a very important part of the infrastructure. > c) Emphasis on actual workflow and usability. > d) It would work for any program, even those without tracker and those > that aren't high profile and aren't usually in the center of attention. > > Could this work? What do you think? > -- > Regards, > Philipp
Hi guys, first of all, as usual in the German language area, I'll apologize beforehand. I left you alone with the idea on purpose, but didn't plan to do so for so long. Also sorry for replying to my own mail. I feel like I have to make the origin of the idea and my intentions clear, in the process of doing so I'll likely offend someone, which is not my intent, I appreciate and value the work put into Linux Audio by all of you. One reason for coming up with the idea is that I'd like to see user wishes like jack support for mumble for the podcasters and jack support for asterisk for the blind, like Julien, come true. Chances that the main developers implement and maintain jack support in their apps are slim at best, but you LADs have the expertise to make it happen. Another small reason are new developers. They rarely know where to start, which app to get involved in etc.. This meta tracker could possibly help to guide them to projects and tasks where help is needed and appreciated. The most important reason however is that Linux Audio currently doesn't fulfill its promise as modular system, but the goal seems to be in reach. I know this is a bit of a bold claim, but I have at least some evidence to back it. The backbone of the modular Linux Audio system is jack, yet it's creator develops a huge monolithic piece of software and has, to my knowledge, never actively supported any of the attempts of solving the session management issue. I'd like to claim here that any modular system, in order to be useful, needs the things: connections (jack), synchronisation (jack transport) and a means of storing and recalling the setup. The last part has apparently been worked on for a long time, but no overall satisfactory solution has come out of it. But now there are two attempts that could fulfill this role. Each with its benefits and drawbacks and neither is able to fulfill the role completely yet. But they are not mutual, they could live side by side, so there seems little in the way of Linux Audio working as it's supposed to. With this goal in reach, another class of problems will become more visible, namely issues between applications. By this I mean mainly synchronisation issues of all kinds. Since it's usually unclear where the issue stems from, developers on either side tend to dismiss it and claim that the other app is buggy. One notable example I believe is jack transport synchronisation between ardour and hydrogen. It took a number of months at least to resolve it, if it is resolved. During that time funny checkboxes crept up in hydrogen that you had to tick in order to workaround the bug in ardour, or so it claimed. This only happened because ardour is such a high profile app, in most other cases I suspect that simply nothing would have happened on either side. So I believe that a meta tracker could function as a central place for this kind of issues and that it could help developers to actually work together to resolve this kind of issues. Thanks for reading. -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
