5 Jun
2010
5 Jun
'10
12:52 p.m.
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
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
5 Jun
5 Jun
1:36 p.m.
On Sat, 05 Jun 2010 13:18:02 +0200
Philipp <hollunder(a)lavabit.com> wrote:
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?
As a user, I think this is a great idea - and a much needed one given
that, as Philipp points out and as we all know, the linux audio system
really works only with multiple interacting applications.
I think it would even be quite easy to set it up.
One feature I believe would be useful is that if I file a "bug"
regarding the interaction of app 1,2 and 3, the relative devs get
automatically mailed and can jump in the discussion
renato
3:59 p.m.
Le 05/06/10 13:45, Renato a écrit :
On Sat, 05 Jun 2010 13:18:02 +0200
Philipp<hollunder(a)lavabit.com> wrote:
> 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?
I think that it's a good idea.
One point with trackers is that each ticket must focus on a specific problem.
Respecting this rule is feasible I think, but may be tricky with
interoperability bugs.
As a user, I think this is a great idea - and a much
needed one given
that, as Philipp points out and as we all know, the linux audio system
really works only with multiple interacting applications.
I think it would even be quite easy to set it up.
One feature I believe would be useful is that if I file a "bug"
regarding the interaction of app 1,2 and 3, the relative devs get
automatically mailed and can jump in the discussion
Being able to add link(s) to upstream ticket(s), as in launchpad, could also be
useful.
--
Olivier
8:40 p.m.
On 5 June 2010 21:58, Olivier Guilyardi <list(a)samalyse.com> wrote:
Le 05/06/10 13:45, Renato a écrit :
>
> On Sat, 05 Jun 2010 13:18:02 +0200
> Philipp<hollunder(a)lavabit.com> wrote:
>
>> 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?
Sure, it's a neat idea. If implemented _properly_, it will at least
serve the function of having a centralised database of such issues.
But what really caught my attention is this:
> One feature I believe would be useful is that if I
file a "bug"
> regarding the interaction of app 1,2 and 3, the relative devs get
> automatically mailed and can jump in the discussion
Now, I'm not very optimistic about co-operation between developers of
app 1, 2 and 3, unless all three are high-profile. The only assurance
is a monetary bounty system.
--
GPG/PGP ID: B42DDCAD
8:58 p.m.
On 5 June 2010 21:58, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I like this idea and I can see a place for it at Linuxaudio.org. A
centralised feature/bug/infrastructure tracker.
I think the hardest part will be to isolate the most important information
and present it in a very obvious way. This could easily get left high and
dry by making the system too complex for the info that is being
aggregated.
A way to start the system could be to collate the info using rss feeds
from the various bug trackers that are already in use.
--
Patrick Shirkey
Boost Hardware Ltd.
Le 05/06/10 13:45, Renato a écrit :
>
> On Sat, 05 Jun 2010 13:18:02 +0200
> Philipp<hollunder(a)lavabit.com> wrote:
>
>> 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?
Sure, it's a neat idea. If implemented _properly_, it will at least
serve the function of having a centralised database of such issues.
But what really caught my attention is this:
> One feature I believe would be useful is that
if I file a "bug"
> regarding the interaction of app 1,2 and 3, the relative devs get
> automatically mailed and can jump in the discussion
Now, I'm not very optimistic about co-operation between developers of
app 1, 2 and 3, unless all three are high-profile. The only assurance
is a monetary bounty system.
6 Jun
6 Jun
12:33 a.m.
On 06/06/2010 04:58 AM, Patrick Shirkey wrote:
I like this idea and I can see a place for it at Linuxaudio.org. A
centralised feature/bug/infrastructure tracker.
I think the hardest part will be to isolate the most important information
and present it in a very obvious way. This could easily get left high and
dry by making the system too complex for the info that is being
aggregated.
A way to start the system could be to collate the info using rss feeds
from the various bug trackers that are already in use.
linuxaudio.org would indeed be a good place for such a tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful.If it slipped behind it could in fact have the opposite effect.
who would be prepared to undertake such a burden? it would need to be
completely automated as the amount of info could be quite substantial
quite quickly... seems to me the devil is in the detail.
g.
12:36 a.m.
On 06/06/2010 08:33 AM, Geoff Beasley wrote:
linuxaudio.org would indeed be a good place for such a
tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful.If it slipped behind it could in fact have the opposite
effect. who would be prepared to undertake such a burden? it would
need to be completely automated as the amount of info could be quite
substantial quite quickly... seems to me the devil is in the detail.
perhaps a centralised,searchable database of existing bugtrackers may be
another option...
g.
14 Jun
14 Jun
2:25 p.m.
Excerpts from Geoff Beasley's message of 2010-06-06 00:36:15 +0200:
On 06/06/2010 08:33 AM, Geoff Beasley wrote:
I think this would be relatively easy to do using the software that
powers openhatch.org, but I don't think it would help with
interoperability bugs. Some trackers are already huge on their own, some
apps don't have trackers, so it would be huge but still inclomplete.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
linuxaudio.org would indeed be a good place for
such a tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful.If it slipped behind it could in fact have the opposite
effect. who would be prepared to undertake such a burden? it would
need to be completely automated as the amount of info could be quite
substantial quite quickly... seems to me the devil is in the detail.
perhaps a centralised,searchable database of existing bugtrackers may be
another option...
g. 
7 Jun
7 Jun
12:06 a.m.
On 06/06/2010 12:33 AM, Geoff Beasley wrote:
On 06/06/2010 04:58 AM, Patrick Shirkey wrote:
>
> I like this idea and I can see a place for it at Linuxaudio.org. A
> centralised feature/bug/infrastructure tracker.
If someone wants to step forward, hosting it under the umbrella (and on
the server) of linuxaudio.org will be the least issue.
> I think the hardest part will be to isolate the
most important
> information
> and present it in a very obvious way. This could easily get left high and
> dry by making the system too complex for the info that is being
> aggregated.
Bug-tracking always requires user & developer interaction (confirm,
reproduce, comment..). Merly aggregating or collecting information won't
do much good.
OTOH I really like the idea to improve interoperability between apps.
> A way to start the system could be to collate the
info using rss feeds
> from the various bug trackers that are already in use.
Testing this idea: http://planet.linuxaudio.org/bugs/
currently collects [only] ardour, jack & qtractor tracker's feeds.
Imagine how this would look with over 50 projects. I doubt it would be
very useful. But things could be improved by using more elaborate
RSS/Atom feed queries..
Anyway, this is a one-way system. Users will need to use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.
The easiest way to supplement this would be a linux-audio-bugs
email-list or just re-use this list.
linuxaudio.org would indeed be a good place for such a
tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful. If it slipped behind it could in fact have the opposite effect.
who would be prepared to undertake such a burden? it would need to be
completely automated as the amount of info could be quite substantial
quite quickly... seems to me the devil is in the detail.
Indeed. Implementing a centralized cross-project bug & feature tracker
- possibly with bounties - can become quite complex; not to mention it
requires quite some effort to maintain it.
Please proof me wrong. It'd be a great thing to have.
robin
5:26 a.m.
On 06/06/2010 12:33 AM, Geoff Beasley wrote:
The feeds provide a link through to the original post so that provides a
way back for contributors and developers.
On 06/06/2010 04:58 AM, Patrick Shirkey wrote:
>
> I like this idea and I can see a place for it at Linuxaudio.org. A
> centralised feature/bug/infrastructure tracker.
If someone wants to step forward, hosting it under the umbrella (and on
the server) of linuxaudio.org will be the least issue.
> I think the hardest part will be to isolate
the most important
> information
> and present it in a very obvious way. This could easily get left high
> and
> dry by making the system too complex for the info that is being
> aggregated.
Bug-tracking always requires user & developer interaction (confirm,
reproduce, comment..). Merly aggregating or collecting information won't
do much good.
OTOH I really like the idea to improve
interoperability between apps.
The bugs feeds is a good start. Did you just set that page up?
I don't like the idea of flooding this list with bug reports. A new list
is an option using the feeds from the bugs page as data. But that is
really just replicating existing functionality. A more productive approach
is to improve on the bugs page now that it exists. For example an "add" /
"submit" new feed button/link would be helpful.
> A way to start the system could be to collate
the info using rss feeds
> from the various bug trackers that are already in use.
Testing this idea: http://planet.linuxaudio.org/bugs/
currently collects [only] ardour, jack & qtractor tracker's feeds.
Imagine how this would look with over 50 projects. I doubt it would be
very useful. But things could be improved by using more elaborate
RSS/Atom feed queries..
Anyway, this is a one-way system. Users will need to use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.
The easiest way to supplement this would be a linux-audio-bugs
email-list or just re-use this list.
linuxaudio.org
would indeed be a good place for such a tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful. If it slipped behind it could in fact have the opposite effect.
who would be prepared to undertake such a burden? it would need to be
completely automated as the amount of info could be quite substantial
quite quickly... seems to me the devil is in the detail.
Indeed. Implementing a centralized cross-project bug & feature tracker
- possibly with bounties - can become quite complex; not to mention it
requires quite some effort to maintain it.
Please proof me wrong. It'd be a great thing to have.
5:09 p.m.
On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
Yeah, but only one at a time; this is not a "meta tracker".
yes; well we have this planet for a few months now (Nov 2009).
see http://wiki.linuxaudio.org/wiki/planet
Making this 2nd planet with feeds from trackers took less than 5 mins.
It's rather a quick experiment to see if something like this can be useful.
I think you are correct. The trick is figuring out how to move the concept
forward without getting bogged down in minor details.
let's keep brainstorming.
robin
On 06/06/2010 12:33 AM, Geoff Beasley wrote:
The feeds provide a link through to the original post so that provides a
way back for contributors and developers.
On 06/06/2010 04:58 AM, Patrick Shirkey wrote:
>
> I like this idea and I can see a place for it at Linuxaudio.org. A
> centralised feature/bug/infrastructure tracker.
If someone wants to step forward, hosting it under the umbrella (and on
the server) of linuxaudio.org will be the least issue.
> I think the hardest part will be to isolate
the most important
> information
> and present it in a very obvious way. This could easily get left high
> and
> dry by making the system too complex for the info that is being
> aggregated.
Bug-tracking always requires user & developer interaction (confirm,
reproduce, comment..). Merly aggregating or collecting information won't
do much good.
OTOH I really
like the idea to improve interoperability between apps.
The bugs feeds is a good start. Did you just set that page up? > A way to start the system could be to collate
the info using rss feeds
> from the various bug trackers that are already in use.
Testing this idea: http://planet.linuxaudio.org/bugs/
currently collects [only] ardour, jack & qtractor tracker's feeds.
Imagine how this would look with over 50 projects. I doubt it would be
very useful. But things could be improved by using more elaborate
RSS/Atom feed queries..
Anyway, this is a one-way system. Users will need to use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.
The easiest way to supplement this would be a linux-audio-bugs
email-list or just re-use this list.
I don't like the idea of flooding this list with
bug reports. A new list
is an option using the feeds from the bugs page as data.
I meant a list for discussion and commenting on bugs, not for
auto-posting/forwarding new bug request there.
But that is
really just replicating existing functionality. A more productive approach
is to improve on the bugs page now that it exists. For example an "add" /
"submit" new feed button/link would be helpful.
There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on
the right.
I don't think automating the submit/add system is a good idea; Marc, Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.
We'll need to update the wiki-page though and improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.
linuxaudio.org would indeed be a good place for such a
tracker, and it
is indeed a good idea but for the issue of 'updatedness' ie; it would
need quite some effort to remain up-to-date and therefore relevant and
useful. If it slipped behind it could in fact have the opposite effect.
who would be prepared to undertake such a burden? it would need to be
completely automated as the amount of info could be quite substantial
quite quickly... seems to me the devil is in the detail.
Indeed. Implementing a centralized cross-project bug & feature tracker
- possibly with bounties - can become quite complex; not to mention it
requires quite some effort to maintain it.
Please proof me wrong. It'd be a great thing to have.
8 Jun
8 Jun
10:31 a.m.
On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
That should be good enough for most people.
On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>
But that is
really just replicating existing functionality. A more productive
approach
is to improve on the bugs page now that it exists. For example an "add"
/
"submit" new feed button/link would be helpful.
There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on
the right.
I don't think automating the submit/add system is
a good idea; Marc, Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.
Agreed.
We'll need to update the wiki-page though and
improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.
It's looking quite useful already. Another idea is to aggregate the bugs
as they are fixed and maintain a record for the most active projects. I
s'pose most of that data can be extracted directly from the trackers? As
in no need for us to write a database specifically for that info.
--
Patrick Shirkey
Boost Hardware Ltd.
10:35 p.m.
On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
That should be good enough for most people.
Alas that's not so simple with most systems.
Only trac is good at that - providing a feed or statistics for recently
resolved and closed bugs, that is.
MantisBT requires the administrator to create a filter [1] and I don't
think it's even possible with the sourceforge tracker. SF.net provides
their own statistics but there's no feed for those.
If googlecode-issue-tracker can do it it's a feature well hidden.
I have not checked flyspray, bugzilla and debbugs.
so long,
robin
[1]
http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&…
On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>
But that
is
really just replicating existing functionality. A more productive
approach
is to improve on the bugs page now that it exists. For example an "add"
/
"submit" new feed button/link would be helpful.
There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on
the right.
I don't think automating the submit/add
system is a good idea; Marc, Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.
Agreed.
We'll need to update the wiki-page though and
improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.
It's looking quite useful already. Another idea is to aggregate the bugs
as they are fixed and maintain a record for the most active projects. I
s'pose most of that data can be extracted directly from the trackers? As
in no need for us to write a database specifically for that info.
10 Jun
10 Jun
4:11 a.m.
On Tue, June 8, 2010 1:35 pm, Robin Gareus wrote:
On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
That makes that idea fairly difficult to implement in the short term.
So far we have the list of apps being tracked on the right hand column,
and add/submit link and the actual feeds. You suggested an extension that
allows tickets to be tracked cross app but I think that is a lot of effort
for minimal gain at this point as there isn't yet a huge user base for the
tracker portal.
I think it would be useful for the idea if we could bring out the user
contribution side a little more before building code to handle cross app
bug tracking.
Maybe a few links to add a new ticket, join the project and donate if the
project has that facility that could be displayed next to each project
and/or item in each feed?
--
Patrick Shirkey
Boost Hardware Ltd.
On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
That should be good enough for most people.
Alas that's not so simple with most systems.
Only trac is good at that - providing a feed or statistics for recently
resolved and closed bugs, that is.
MantisBT requires the administrator to create a filter [1] and I don't
think it's even possible with the sourceforge tracker. SF.net provides
their own statistics but there's no feed for those.
If googlecode-issue-tracker can do it it's a feature well hidden.
I have not checked flyspray, bugzilla and debbugs.
so long,
robin
[1]
http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&…
On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>
But that
is
really just replicating existing functionality. A more productive
approach
is to improve on the bugs page now that it exists. For example an
"add"
/
"submit" new feed button/link would be helpful.
There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on
the
right.
I don't think automating the submit/add
system is a good idea; Marc,
Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.
Agreed.
We'll need to update the wiki-page though and
improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.
It's looking quite useful already. Another idea is to aggregate the bugs
as they are fixed and maintain a record for the most active projects. I
s'pose most of that data can be extracted directly from the trackers? As
in no need for us to write a database specifically for that info.
13 Jun
13 Jun
2:15 p.m.
On 06/10/2010 04:11 AM, Patrick Shirkey wrote:
On Tue, June 8, 2010 1:35 pm, Robin Gareus wrote:
Adding extra information is not a big deal. The problem is: All trackers
require a user to log in in order to access the "submit ticket" page..
and the minority of them has OpenID or OAuth enabled.
Clicking on the link in the "Subscriptions" sidebar already gets you to
the main site of each trackers from where you can proceed to "add
ticket" if you're logged in there.
If you want to go ahead and improve the layout: I can give you write
permissions on linuxaudio.org:/var/lib/planet/templates/ and
/etc/planet-bugs.conf
One idea would be to create a linuxaudio account on all upstream
trackers and provide a form on LAO that submits tickets upstream using
this account; but it'd be a major task to do so: SPAM filtering,
aggregate upstream versions & options; templates for the multitude of
different trackers out there etc etc, not to mention handling email
notifications that come back from the trackers.
2c,
robin
On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
That makes that idea fairly difficult to implement in the short term.
So far we have the list of apps being tracked on the right hand column,
and add/submit link and the actual feeds. You suggested an extension that
allows tickets to be tracked cross app but I think that is a lot of effort
for minimal gain at this point as there isn't yet a huge user base for the
tracker portal.
I think it would be useful for the idea if we could bring out the user
contribution side a little more before building code to handle cross app
bug tracking.
Maybe a few links to add a new ticket, join the project and donate if the
project has that facility that could be displayed next to each project
and/or item in each feed?
On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
Alas that's not so simple with most systems.
Only trac is good at that - providing a feed or statistics for recently
resolved and closed bugs, that is.
MantisBT requires the administrator to create a filter [1] and I don't
think it's even possible with the sourceforge tracker. SF.net provides
their own statistics but there's no feed for those.
If googlecode-issue-tracker can do it it's a feature well hidden.
I have not checked flyspray, bugzilla and debbugs.
so long,
robin
[1]
http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&…
On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>
> But that is
> really just replicating existing functionality. A more productive
> approach
> is to improve on the bugs page now that it exists. For example an
> "add"
> /
> "submit" new feed button/link would be helpful.
There's a 'tiny' link labeled "FAQ & Subscribe" in the bar on
the
right.
That should be good enough for most people.
I don't think automating the submit/add
system is a good idea; Marc,
Ico
& me are are quite quick filtering SPAM and editing the planetplanet
config-file.
Agreed.
We'll need to update the wiki-page though and
improve the HTML-template
for "planet bug". Anyway so far it's just an experiment, not a
maintained service.
It's looking quite useful already. Another idea is to aggregate the bugs
as they are fixed and maintain a record for the most active projects. I
s'pose most of that data can be extracted directly from the trackers? As
in no need for us to write a database specifically for that info.
14 Jun
14 Jun
12:54 a.m.
On Sun, June 13, 2010 5:14 am, Robin Gareus wrote:
On 06/10/2010 04:11 AM, Patrick Shirkey wrote:
Might as well do that. I'm not gonna be able to make any progress for the
next couple of weeks but I will be able to get stuck into it at some
point.
On Tue, June 8, 2010 1:35 pm, Robin Gareus wrote:
Adding extra information is not a big deal. The problem is: All trackers
require a user to log in in order to access the "submit ticket" page..
and the minority of them has OpenID or OAuth enabled.
Clicking on the link in the "Subscriptions" sidebar already gets you to
the main site of each trackers from where you can proceed to "add
ticket" if you're logged in there.
If you want to go ahead and improve the layout: I can give you write
permissions on linuxaudio.org:/var/lib/planet/templates/ and
/etc/planet-bugs.conf
On 06/08/2010 10:31 AM, Patrick Shirkey wrote:
That makes that idea fairly difficult to implement in the short term.
So far we have the list of apps being tracked on the right hand column,
and add/submit link and the actual feeds. You suggested an extension
that
allows tickets to be tracked cross app but I think that is a lot of
effort
for minimal gain at this point as there isn't yet a huge user base for
the
tracker portal.
I think it would be useful for the idea if we could bring out the user
contribution side a little more before building code to handle cross app
bug tracking.
Maybe a few links to add a new ticket, join the project and donate if
the
project has that facility that could be displayed next to each project
and/or item in each feed?
On Mon, June 7, 2010 8:09 am, Robin Gareus wrote:
> On 06/07/2010 05:26 AM, Patrick Shirkey wrote:
>>
>> But that is
>> really just replicating existing functionality. A more productive
>> approach
>> is to improve on the bugs page now that it exists. For example an
>> "add"
>> /
>> "submit" new feed button/link would be helpful.
>
> There's a 'tiny' link labeled "FAQ & Subscribe" in the bar
on the
> right.
>
That should be good enough for most people.
> I don't think automating the submit/add system is a good idea; Marc,
> Ico
> & me are are quite quick filtering SPAM and editing the planetplanet
> config-file.
>
Agreed.
> We'll need to update the wiki-page though and improve the
> HTML-template
> for "planet bug". Anyway so far it's just an experiment, not a
> maintained service.
>
It's looking quite useful already. Another idea is to aggregate the
bugs
as they are fixed and maintain a record for the most active projects.
I
s'pose most of that data can be extracted directly from the trackers?
As
in no need for us to write a database specifically for that info.
Alas that's not so simple with most systems.
Only trac is good at that - providing a feed or statistics for recently
resolved and closed bugs, that is.
MantisBT requires the administrator to create a filter [1] and I don't
think it's even possible with the sourceforge tracker. SF.net provides
their own statistics but there's no feed for those.
If googlecode-issue-tracker can do it it's a feature well hidden.
I have not checked flyspray, bugzilla and debbugs.
so long,
robin
[1]
http://www.futureware.biz/blog/index.php?title=rss_feeds_in_mantis_1_0_0a3&…
One idea would be to create a linuxaudio account on
all upstream
trackers and provide a form on LAO that submits tickets upstream using
this account; but it'd be a major task to do so: SPAM filtering,
aggregate upstream versions & options; templates for the multitude of
different trackers out there etc etc, not to mention handling email
notifications that come back from the trackers.
I think the main issue right now is doing enough to make it useful without
investing too much time into it. A single LAO account seems like a lot of
hassle for not much gain and in a way reinventing the wheel. If we
implement support for all OpenID type protocols for sharing logins and
encourage developers to enable that feature for their trackers that would
take us a fairly large step forward.
openID, oAuth, facebook, wordpress, google connect,
Which ones do we need to support and which ones are most likely to get
people using the system? Given that the idea is to make it easy for new
users to get involved, IMO we should aim to support the most popular
methods and not just the open source options.
--
Patrick Shirkey
Boost Hardware Ltd.
7 Jun
7 Jun
2:26 p.m.
On Sunday 06 June 2010 18:06:43 Robin Gareus wrote:
Anyway, this is a one-way system. Users will need to
use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.
Just a central account function would be very helpful. Register at
tracker.linuxaudio.org and be able to submit to any upstreams tracker with
that one account.
all the best,
drew
5:12 p.m.
On 06/07/2010 02:26 PM, drew Roberts wrote:
On Sunday 06 June 2010 18:06:43 Robin Gareus wrote:
With OAuth and OpenID this is possible; but not all trackers support
those standards; besides it only solves a side issue: user-accounts.
Singing up on each tracker is a one-time only job and much easier than
filing a proper bug report; so that part can actually be neglected.
Let's play through an example:
1) you file a bug report concerning sync between Ardour & Hydrogen
on tracker.linuxaudio.org
2) the tracker automatically forwards those bugs upstream using your
account.
3) On the Ardour tracker there's a quick response saying it's a problem
with JACK-latency compensation in Hydrogen and the ticket is closed
there.
4) tracker.lao recognizes that update and forwards the comment to the
hydrogen bug-tracker
step (2) could be done if upstream tackers support OAuth;
there's a module for Trac and Mantis; but none for Bugzilla yet.
sf.net apparently has it's own interface that allows to forwards bugs.
I dunno about gna.org.
NTL it'll be some work to come up with templates for all those systems.
step (4) will tricky It requires correlating information from step (1,2)
and interpreting the reply from step (3).
Developing such a system will be at least a week of full-time work and
then a few months to test, debug and style it; not including getting
some patches upstream into trackers who require it.
Well, I don't think LAO would be the only community interested in having
such a setup. A quick google-search did not reveal a similar FLOSS
system; did any of you guys stumble over something like that?
ciao,
robin
Anyway, this is a one-way system. Users will need
to use
upstream-trackers to submit information. This somehow undermines the
idea of providing feedback for interop issues at a central location.
Just a central account function would be very helpful. Register at
tracker.linuxaudio.org and be able to submit to any upstreams tracker with
that one account. all the best,
drew
7:37 p.m.
On Monday 07 June 2010 11:12:36 you wrote:
Singing up on each tracker is a one-time only job and
much easier than
filing a proper bug report; so that part can actually be neglected.
Actually, I don't think it can be properly neglected. I have bailed on
submitting a bug report more than once at this step. Sometimes intending to
come back later and sign up and never getting back around to it and sometimes
just not wanting the hassle.
Perhaps I am unique and it can be properly neglected but I somehow doubt it.
all the best,
drew
5 Jun
5 Jun
11:50 p.m.
On Saturday 05 June 2010 14:40:35 Ray Rashif wrote:
The only assurance
is a monetary bounty system.
Might be possible to leave out the monetary bit at least. How about credits on
a musicians next release as a bounty for instance? Other way out bounties?
all the best,
drew
7 Jun
7 Jun
12:10 a.m.
On 06/05/2010 11:50 PM, drew Roberts wrote:
On Saturday 05 June 2010 14:40:35 Ray Rashif wrote:
> The only assurance
> is a monetary bounty system.
I disagree.
Might be possible to leave out the monetary bit at
least. How about credits on
a musicians next release as a bounty for instance? Other way out bounties?
whatever. Just don't force money on people who don't want it.
Money corrupts.
14 Jun
14 Jun
2:07 p.m.
Excerpts from Robin Gareus's message of 2010-06-07 00:10:38 +0200:
On 06/05/2010 11:50 PM, drew Roberts wrote:
I also don't think that a monetary bounty system is a good idea. Besides
a personal dislike for it there are strong indications that it simply
doesn't work (I believe Paul can tell a tale about the huge gap between
bounty and actual work hours).
There are lots of other things that developers need and users can offer.
The first thing obviously being to follow through with the bug they posted,
to test and work with the devs to resolve it. Other things that came to
my mind are documentation, video tutorials, graphics, whatever other
skills the user possesses and the developer needs, something can be done
by anyone.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Saturday 05 June 2010 14:40:35 Ray Rashif
wrote:
> The only assurance
> is a monetary bounty system.
I disagree.
Might be possible to leave out the monetary bit
at least. How about credits on
a musicians next release as a bounty for instance? Other way out bounties?
whatever. Just don't force money on people who don't want it.
Money corrupts.
16 Jun
16 Jun
1:34 a.m.
Excerpts from Renato's message of 2010-06-05 13:45:54 +0200:
On Sat, 05 Jun 2010 13:18:02 +0200
Philipp <hollunder(a)lavabit.com> wrote:
Sorry everyone that I'm very slow at replying, especially to long and
elaborate mails (this is not one of those). I have important exams this
month, so I have neither a lot of time nor mind for it. However, I'll
try to keep the idea alive.
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?
As a user, I think this is a great idea - and a much needed one given
that, as Philipp points out and as we all know, the linux audio system
really works only with multiple interacting applications. I think it would even be quite easy to set it up.
I believe so too, at least in the simplest form, a wiki.
One feature I believe would be useful is that if I
file a "bug"
regarding the interaction of app 1,2 and 3, the relative devs get
automatically mailed and can jump in the discussion
renato
It would be nice, yes, but I'm not totally sure this is possible using a
wiki.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
13 Jul
13 Jul
8:26 p.m.
Excerpts from Philipp Überbacher's message of 2010-06-16 01:34:24 +0200:
Excerpts from Renato's message of 2010-06-05
13:45:54 +0200:
I do have more time now, but since very few devlopers showed interest
in the idea I have to assume that either the problems I saw aren't very
common (yet?) or the solution is considered not helpful. Anyway,
there's little interest in it at this time, maybe the idea will be picked
up at a later time. I won't spend time on it now and I would like to
thank everybody who put thought and time into it.
--
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen
offen." Bertolt Brecht, Der gute Mensch von Sezuan
On Sat, 05 Jun 2010 13:18:02 +0200
Philipp <hollunder(a)lavabit.com> wrote:
Sorry everyone that I'm very slow at replying, especially to long and
elaborate mails (this is not one of those). I have important exams this
month, so I have neither a lot of time nor mind for it. However, I'll
try to keep the idea alive.
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?
As a user, I think this is a great idea - and a much needed one given
that, as Philipp points out and as we all know, the linux audio system
really works only with multiple interacting applications. I think it would even be quite easy to set it up.
I believe so too, at least in the simplest form, a wiki.
One feature I believe would be useful is that if
I file a "bug"
regarding the interaction of app 1,2 and 3, the relative devs get
automatically mailed and can jump in the discussion
renato
It would be nice, yes, but I'm not totally sure this is possible using a
wiki.
13 Jun
13 Jun
12:42 p.m.
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
2:14 p.m.
On 06/13/2010 12:42 PM, Philipp Überbacher wrote:
Excerpts from Philipp's message of 2010-06-05
13:18:02 +0200:
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
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.
5294
days inactive
5332
days old
linux-audio-dev@lists.linuxaudio.org
25 comments
9 participants
participants (9)
-
drew Roberts -
Geoff Beasley -
Olivier Guilyardi -
Patrick Shirkey -
Philipp -
Philipp Überbacher
-
Ray Rashif -
Renato -
Robin Gareus