On 06/13/2010 12:42 PM, Philipp Überbacher wrote: > 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.
The motivations are clear - you may have gotten some details wrong (eg Paul is working on quite a lot besides ardour) - but the tenor is right. The problem is: how to implement and maintain it? Just setting up a tracker is easy; getting people to use and listen to it is the first hurdle. Integrating it with upstream trackers the second. Do you know of a system up for the task that we can install without large development on our side? If you have a good idea or elegant prototype, we can hook you up to manage the tracker.linuxaudio.org vhost. None of the people involved in LAO [1] are currently available for such a task; well, maybe Patrick is?! Cheers! robin [1] http://lists.linuxaudio.org/pipermail/consortium/2010-April/002036.html _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
