Re: [LAD] meta issue tracker idea

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
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev