Re: [LAD] meta issue tracker idea

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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Jun 13 16:15:02 2010