hi I think that both sides are right:
1) people who express kudos to FTP-masters for express accepting new packages due to the C++ name transitions 2) Anand Kumria and Thaddeus Black criticizing FTP-masters for never addressing 'mplayer' 'xvidcap' 'rte' and such I can understand why nobody in the ftp team addresses 'mplayer' 'xvidcap' 'rte' : suppose you are a ftp-master and have 15minutes spare: you check into the NEW queue, spot some transitional packages, run a quick script to check that they were renamed accordingly, and give green light. To address 'mplayer', it would take more than 15 minutes; and it would mean reading a lot of code and debian-legal discussion, and taking sides and expressing an important opinion..... hey that is a lot of work .... so 'mplayer' is always delayed. So , ftp-master team is not doing a _fantastic_ job, (as Jay thinks), they are doing the _most convenient_ job. The _fantastic_ job was the job of people who discussed mplayer on d-devel and d-legal, and reached an agreement that 'mplayer' may enter into Debian, (maybe w/o MPEG2 encoding [1]). That work is currently completely disregarded by the ftp team. Running a script to check that /libblah1c2/ has been properly renamed to /libblah1c2a/ is not that _fantastic_. Solving an outstanding problem is _fantastic._ The paradox is that, if you sum up 15minutes for each package in the NEW queue, you easily total many many hours of work.... more than enough to address 'mplayer' 'xvidcap' 'rte'. In my opinion, considering that the release of etch is 15 months away, there is no need today to concentrate only on accepting transitional new package; it would be instead nice to use these 15months to solve the mplayer stalemate (that has been waiting more than 876 days). indeed, when [1] was written, sarge's release was near, and 'mplayer' was not top priority; now the situation is quite different; there is need to consider 'mplayer' low priority forever; if the ftp team does care a little bit, then this is a good timeframe. BTW: I know that 'mplayer' has always been fishy business in Debian.... but what did 'xvidcap' ever do wrong? AFAICT the only problem may be that 'xvidcap' contains FFMPEG code ; but FFMPEG has been in Debian for quite long now, so I do not really understand what is going on here. a. [1] http://lists.debian.org/debian-devel/2005/04/msg00997.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]