On 06/14/2010 03:51 PM, Philipp wrote:
> --- Begin forwarded message from Philipp Überbacher ---
> From: Philipp Überbacher <hollunder@lavabit.com>
> To: Robin Gareus <robin@gareus.org>
> Date: Mon, 14 Jun 2010 13:31:40 +0200
> Subject: Re: SPOOFED: Re: [LAD] meta issue tracker idea
>
> Sorry, this message went to Robin only by accident.
I'm pasting my [off-list] reply in a similar fashion.
> Excerpts from Robin Gareus's message of 2010-06-13 14:14:13 +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.
>
> What I meant was that he never implemented anything that could have
> solved the session management issue in ardour, be it lash, any of its
> predecessors or anything more recent. I know that torben worked on a
> jack_session patch for ardour, but as long as it's not in ardour it
> doesn't help much. The reasons for this could be manifold and I won't
> speculate at this point.
>
>> 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
>
> I think you're thinking more complicated than I did initially. Who says
> a custom tracker, the possibility of integration with upstream trackers
> and whatever other fancy stuff you guys came up with is really
> necessary?
I doubt that many upstream authors will want to use "yet another
bugtracking/discussion" system.
The reasons may be manifold: it may not integrate nicely with source
revision tracking (which bug got fixed in which revision); it may not
integrate with existing bounty or donation systems, etc.
I appreciate the input and ideas and I agree that it would be
> nice, but necessary?
I'm just playing the devil's advocate here.
> Are you sure it's not more trouble than worth at
> this point?
No but if we pull this off it should be useful from the beginning
otherwise it will not fly.
It does not to be perfect in it's first revision; but it must be good
enough to catch developer's interest.
> If a custom tracker should be developed at some point, then
> it shouldn't happen behind LAD doors but together with other parties who
> could benefit from it and likely have more expertise in that area.
>
> The closest existing thing I know is http://openhatch.org/, which pulls
> all or some bugs from lots of trackers, but I'm not sure it's close to
> what is needed here.
AFAICT openhatch tackles a different problem: get people on a project. I
don't know if it can be useful for improving interoperability and
inter-project problems; but it could be a start.
> My idea for the near future was to simply use an existing wiki, possibly
> on linuxaudio.org (mainly because of the domain name). In the simplest
> form I believe, tags could be used for applications (to find all issues
> involving the specific app), pages for the issues and page subscriptions
> for notification.
Those features are all already present at wiki.linuxaudio.org.
There's been some complaints about the current style; but no-one has
stepped forward and provided a better template yet. FWIW you can switch
the look&feel at http://wiki.linuxaudio.org/wiki/user/rgareus
the "experimental" there is a contender for the new default. but it's
not yet XHTML clean and requires javascript.
If one wants to pick up a project he/she can already find
http://wiki.linuxaudio.org/apps/categories/unmaintained
and
http://wiki.linuxaudio.org/apps/categories/dead_link
From the top-of-my head, here's how we could start:
go to http://wiki.linuxaudio.org/wiki/bugs/ISSUE
Where ISSUE eg: synchronization
- create or edit the wiki-page
- describe the problem
- add links to affected software
eg. [[apps:all:ardour]], [[apps:all:hydrogen]]
- optionally add external links to upstream trackers.
- optionally add {{rss>TRACKER-FEED-URL}} for issue upstream.
The backlinks ("what links here") feature of the eg.
http://wiki.linuxaudio.org/apps/all/hydrogen
page will show related bugs. It will be easy to make a "show only
backlinks in the 'bug' namespace" feature.)
Once we have a few test/example pages we can add wiki-shortcuts to ease
the workflow. There's also the possibility to have a small form that
will create a new wiki-page according to a template using
http://www.dokuwiki.org/plugin:bureaucracy
Then we'll "only" need to make developers of said application aware of
the bug-reports:
This could happen using feeds:
http://wiki.linuxaudio.org/feed.php?mode=list&ns=wiki:bugs:ISSUE
or subscribing them to the "page change notification" of said issue.
or it can be one of us, playing man-in-the-middle forwarding these bug
upstream.
A nice feature would be subscribe to 'pages with tag XXX'; that is not
yet possible; but I can whip up a plugin for that if once need it.
> I'm no expert on wikis, so I'm not sure whether there
> are more features that could be used to fulfill more of what we'd
> want.
right; so far we have a problem description and brainstorm about
possible solutions but not actually a use-case list of "what we want".
Cheers!
robin
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jun 14 20:15:02 2010
This archive was generated by hypermail 2.1.8 : Mon Jun 14 2010 - 20:15:02 EEST