Hi the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist * change its config so every bug gets sent to ffmpeg-devel * create a ffmpeg-bugs ML and change the bug trackers config so every bug gets sent to it * switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs comments, suggestions, flames, ...? -- Michael
On Mon, Jul 11, 2005 at 04:54:22PM +0200, Michael Niedermayer wrote:
Hi
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist * change its config so every bug gets sent to ffmpeg-devel * create a ffmpeg-bugs ML and change the bug trackers config so every bug gets sent to it * switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
comments, suggestions, flames, ...?
i dunno.. but i agree sf bug tracker should be disabled. i know i won't bother with anything that require a web interface. it's too much trouble. rich
On Mon, Jul 11, 2005, Michael Niedermayer wrote:
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
We've been using Trac for 2 months in VLC developement and it actually works quite well. It features a wiki (which we don't use), bug reporting features (which we limited to users with svn accounts only) and roadmap planning as well as an svn source browser. You can check it out here : http://trac.videolan.org/vlc/ I don't know if that's the kind of tool you're looking for but it sure is usefull (you can do all kind of neat things such as closing bugs in commit messages ...) -- Antoine Cellerier dionoea
Hi, Michael Niedermayer wrote:
Hi
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist * change its config so every bug gets sent to ffmpeg-devel * create a ffmpeg-bugs ML and change the bug trackers config so every bug gets sent to it * switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
comments, suggestions, flames, ...?
A bug tracker could be usefull to keep a trace of unresolved bugs, but I don't know nice bug trackers...
* switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
comments, suggestions, flames, ...?
How about mantis? http://www.mantisbt.org/ Tommi
Hi On Tuesday 12 July 2005 10:46, Tommi Sakari Uimonen wrote:
* switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
comments, suggestions, flames, ...?
How about mantis?
does it have a email interface? so that all changes get posted to some mailinglist and replies sent to that list by people will show up in the bug tracker? it also seems to depend upon mysql which is something some people here wont like except these and overall after a very very quick look it seems much better then the SF tracker or bugzilla [...] -- Michael
Michael Niedermayer wrote:
How about mantis? http://www.mantisbt.org/
does it have a email interface?
It sends emails, but you can not add reports by sending mails to mantis. The only way to add a bug/an issue is to use the web interface. We use mantis at work and it does its job pretty well. Tobias
Hi, Michael Niedermayer wrote:
Hi
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist
the sf-tracker should be killed.
* change its config so every bug gets sent to ffmpeg-devel * create a ffmpeg-bugs ML and change the bug trackers config so every bug gets sent to it * switch to a different bug tracker but it must have a working email & web interface and be intuitive (= NOT bugzilla) and config it so bugs get sent to ffmpeg-devel/bugs
comments, suggestions, flames, ...?
And I think that a combined bug/patch tracker would be good. What I miss is a simple weblist of reported bugs and pending/unapplied patches. Bugs and patches should also be able to be submitted with both web and email interfaces. Here is a list of 134 bug tracker projects from freshmeat. There should be something of use there. http://freshmeat.net/browse/846/ MvH Benjamin Larsson
Hi On Tuesday 12 July 2005 11:55, Benjamin Larsson wrote:
Hi,
Michael Niedermayer wrote:
Hi
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist
the sf-tracker should be killed.
ok it seems theres strong agreement about this among everyone ... but, does anyone know how? i can make it non public but that means people wont be able to view the existing reports anymore and i dont want that ... [...] -- Michael
Michael Niedermayer wrote:
Hi
On Tuesday 12 July 2005 11:55, Benjamin Larsson wrote:
Hi,
Michael Niedermayer wrote:
Hi
the current sf bug tracker is checked far too rarely and pretty much just by me, we should either * kill it and just use the mailinglist
the sf-tracker should be killed.
ok it seems theres strong agreement about this among everyone ... but, does anyone know how? i can make it non public but that means people wont be able to view the existing reports anymore and i dont want that ...
[...]
Whatever solution is used, it should not *require* anything beyond the current mailing lists except for people with CVS access; meaning, if there is a web-based system, it should send copies of new bugs to ffmpeg-devel, and of status changes to ffmpeg-cvs. One advantage of a web-based system for new bug reports is that it could check automatically for the usual irritants like non-current build numbers, lack of command line, lack of output... OTOH *another* mailing lists would be a Bad Thing (TM). There is enough yoyo now between ffmpeg-user and ffmpeg-devel, lets not add to the confusion? HaND, -- Michel Bardiaux R&D Director MediaXim S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41
participants (8)
-
banan＠student.ltu.se -
castet.matthieu＠free.fr -
dalias＠aerifal.cx -
dionoea＠via.ecp.fr -
listaccount＠e-tobi.net -
mbardiaux＠mediaxim.be -
michaelni＠gmx.at -
tuimonen＠cc.hut.fi