On 06/14/2010 03:51 PM, Philipp wrote: > --- Begin forwarded message from Philipp Überbacher --- > From: Philipp Überbacher <[email protected]> > To: Robin Gareus <[email protected]> > 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
