[Mplayer-users] bugreports,

[Arpi]

Hi,

> > > so that I would know about what happens
> > Every bugreport is read, and (if not just a simple RTFM;) answered.
> Well, what about my bugreport about DOCS/DEBIAN documentation?
It's Telenieko's work, i don't know what's with him. I didn't see him for a
while. Someone should fix it, but I can't because i don't know debian
(slackware rulez :))

> > > someone's working on it, marked as known and left for feature
> > DOCS/BUGS DOCS/TODO
> Not ergonomic way of communication.
> also - I've got not DOCS/BUGS DOCS/TODO file in my quite fresh cvs copy,
RTFM man cvs :)))))))))
it's there, so you must check your system, or rm -rf * and checkout again.

oh, are you using cvs snapshots?
hmm. just downloaded the latest:
root at linux:~/mp# tar -xyf mplayer-main-20010515.tar.bz2
root at linux:~/mp# ls main/DOCS
AUTHORS     ChangeLog.mpeg  MPlayer-FAQ  SPEED           example.conf
BUGREPORTS  DEBIAN          MTRR         Spanish/        inttypes.h
BUGS        DVD             OpenDivX     TODO            mplayer.1
CDROM       DVD-FAQ         README       TVout-G400      tech-eng.txt
CODECS      Hungarian/      Russian/     VIDEOCARDS      tech-hun.txt
CVS/        INSTALL         SDL          codecs-in.html
ChangeLog   LIRC            SOUNDCARDS   codecs.conf

there are both TODO and BUGS along the others.

> also - it requires everyone to download latest CVS to check what's the
> current status, and not everyone uses cvs or even have access to such
> soft. And that's not what cvs is for. And there is now way to acces this
> file via say http.
you mean no way or now way? later is true, but not now, it's for a while.
it's downloadable from both http and ftp along the anonymous cvs.

> > > When I send something to mplayer-users it gets randomly ignored
> > Never.
never say never!
> Sometimes.
true :(
why? we got tons of mails:
1. usual questions (most): Gabucino send some RTFM for him. and hoping that
   people learn reading docs once a day.
   sometimes he sends bad RTFM. it's normal, he isn't perfect yet =)
2. non-usual but easy questions (some): we answer them if we can
3. problems (many): we ask them for correct, full bugreport
4. problems with correct bugreport (about one per month):
   we try to help, and fix. sometimes we has no idea how to do it.
   if you posted a correct bugreport, you MUST expect a correct answer.
   if you don't get it in a few days, then repeat it please, we forgot!
   i'll answer such bugreports only if the bug is in _my_ code, or I
   already know that bug (but then it must be in DOCS/BUGS, so goto 1.)
5. feature requests: simply skip :)  at least i skip them, i have plans
   for about next 2 years, and don't want to extend my already long TODO.
   and usually they are already on my TODO. and usually on DOCS/TODO too.
6. problems with under-development code (for example a-v sync at seek, sub
   sync etc): i skip them, because i or someone else is working on it.
   when i finish the code, i'll send an announce to mplayer-users and ask
   to test it. if it's still buggy, then you should re-post your bugreport

> That's why I'm proposing using some ticketing system, sourceforge
> offers such functionality.
> That way anyone knows IF their report was lost in transport or maybe
> reached it's destination but got marked as RTFM.

if you sent the correct bugreports (see DOCS/BUGREPORTS) then you did it.
you have to wait for the answer. if you think thatit's forgotten, then
repeat it, or just ask the status of the bug.

you must know that we are not paid for this project, and we are doing
it in our spare time. most of us is going to school or working, so
sometimes we has no time for tracking bugs.
but - as i see - the problem is with bugs type 1,2,3,5 and 6.
i don't lost correct bugreports, expect if i absolutely have no idea what
is it (and then wait for the others, maybe they know as usual).

i see no sense of SF's bugtracking system, I'm sure that it will
be flooded with type 1-3,5,6 bugreports too. with the disadvantage
that maybe other users can help here on teh list, while they will
never read others bugs in the bugtracking system.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu

_______________________________________________
Mplayer-users mailing list
Mplayer-users at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-users