> On 5 June 2010 21:58, Olivier Guilyardi <list@email-addr-hidden> wrote:
>> Le 05/06/10 13:45, Renato a écrit :
>>>
>>> On Sat, 05 Jun 2010 13:18:02 +0200
>>> Philipp<hollunder@email-addr-hidden> 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.
>
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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Sun Jun 6 00:15:03 2010
This archive was generated by hypermail 2.1.8 : Sun Jun 06 2010 - 00:15:03 EEST