Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: The ffmpeg library in debian is a problem case and probably should not be in there. That issue hasn't been decided yet and till then anything using it stays stuck. Really? Excellent then. I would expect that gstreamer0.10-ffmpeg, recently uploaded, to be stuck in NEW for a year (at least) then. If it isn't then your theory is wrong. What you are saying that is that a sceanario such as: - a company (e.g. Unisys) asserting a patent on - a file format (e.g. GIF) which has - a library (e.g. libgif) which is used by - an application (e.g. gimp) should result in further uploads of the gimp being held indefinately in the NEW queue until such time as any perceived library patent problem is resolved. If gimp contained the libgif source code then yes. For that and code/bug duplicating reasons. So if you run into such a case better make sure not to get gimp into the NEW queue or it stays there for a while. I'd argue that either: - the library, and all dependant program be removed from the archive - that applications merely linked to the library be allowed in but that the library maintainer be asked to remove the offending code In the spirit of Anthony's blog entry [1], I've CC'd him for an informal opinion about that. Both would be ok. But this case doesn't fall under this. It contains a copy of the source it seems. Imho that alone is already grounds for rejection or we create a situation like zlib where every package had a copy and the same security exploit. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, Dec 21, 2005 at 03:21:07PM +0100, Goswin von Brederlow wrote: Anand Kumria [EMAIL PROTECTED] writes: On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote: Anand Kumria [EMAIL PROTECTED] writes: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Guessing by the name alone I would say this is a patent issue like mplayer and therefore a problem package that is not likely to get resolved anytime soon. But that is just a guess. And it is an incorrect guess. xvidcap itself uses libraries already in Debian. But thanks for playing guess the mind of the ftp-masters. Was it fun? Yes and I guessed right it seems. I think you've been smoking too much. The ffmpeg library in debian is a problem case and probably should not be in there. That issue hasn't been decided yet and till then anything using it stays stuck. Really? Excellent then. I would expect that gstreamer0.10-ffmpeg, recently uploaded, to be stuck in NEW for a year (at least) then. If it isn't then your theory is wrong. What you are saying that is that a sceanario such as: - a company (e.g. Unisys) asserting a patent on - a file format (e.g. GIF) which has - a library (e.g. libgif) which is used by - an application (e.g. gimp) should result in further uploads of the gimp being held indefinately in the NEW queue until such time as any perceived library patent problem is resolved. I'd argue that either: - the library, and all dependant program be removed from the archive - that applications merely linked to the library be allowed in but that the library maintainer be asked to remove the offending code In the spirit of Anthony's blog entry [1], I've CC'd him for an informal opinion about that. For non problem cases the NEW queue was never as fast as now so congratulation of improving the NEW queue so much already. Giving your past month performance I'm sure the few remaining issues can be resolved in time as well. Ignoring anything 2 weeks or newer I count only 7 packages. This is great. Maybe you are a fan of being left in limbo, or like the perverbial Schrödinger's cat, but even a bad process can benefit from assurances. A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. And would result in mplayer being uploaded again and again everytime someone forgets it was there before. Beter to have it stuck but documented why. Surely it be better to document that in the REJECT FAQ that a package: - with a particular name - or linked to a particular library - isn't likely to be looked at prior to autoREJECT occuring Then it wouldn't even be stuck. Anand [1]: http://azure.humbug.org.au/~aj/blog/2005/12/11 -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote: Anand Kumria [EMAIL PROTECTED] writes: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Guessing by the name alone I would say this is a patent issue like mplayer and therefore a problem package that is not likely to get resolved anytime soon. But that is just a guess. And it is an incorrect guess. xvidcap itself uses libraries already in Debian. But thanks for playing guess the mind of the ftp-masters. Was it fun? Yes and I guessed right it seems. The ffmpeg library in debian is a problem case and probably should not be in there. That issue hasn't been decided yet and till then anything using it stays stuck. And yes, that should be documented or at least communicated to the maintainer. For non problem cases the NEW queue was never as fast as now so congratulation of improving the NEW queue so much already. Giving your past month performance I'm sure the few remaining issues can be resolved in time as well. Ignoring anything 2 weeks or newer I count only 7 packages. This is great. Maybe you are a fan of being left in limbo, or like the perverbial Schrödinger's cat, but even a bad process can benefit from assurances. A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. And would result in mplayer being uploaded again and again everytime someone forgets it was there before. Beter to have it stuck but documented why. Anand MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: etch release plan (was Re: congratulations to our ftp-master team)
sorry, I was remembering incorrectly the dates (and by no means meaning that I want the release to be 3 months later than what Steve announced) a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Javier Fernández-Sanguino Peña wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: I *guess* mplayer could do likewise. MPlayer was once very picky regarding the versions of ffmpeg that it does compile with. Moreover MPlayer want to link all core libraries together (for performance reasons). So I think not. Notice, in any case, that the xvidcap packages in NEW *don't* use ffmpeg, the source code is there: $ ldd /usr/bin/xvidcap . 'ldd' does not mean anything: most versions of xvidcap ship a copy of ffmpeg in their own sources: $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3-p7.tar.gz $ tar xzf xvidcap-1.1.3-p7.tar.gz $ du -s xvidcap-1.1.3-p7/ffmpeg/ 6420xvidcap-1.1.3-p7/ffmpeg/ $ wget http://heanet.dl.sourceforge.net/sourceforge/xvidcap/xvidcap-1.1.3.tar.gz $ tar xzf xvidcap-1.1.3.tar.gz $ du -s xvidcap-1.1.3/ffmpeg/ 6340xvidcap-1.1.3/ffmpeg/ a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I did ask, Re: congratulations to our ftp-master team
Dear Jeroen and everybody, here attached is an email I sent in September. Yes, I did ask to ftp-masters clarifications about your proposal in http://lists.debian.org/debian-devel/2005/04/msg00997.html and never received a reply. Jeroen van Wolffelaar wrote: While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? yes AFAIK mencoder cannot encode MPEG2 in this version (that is in NEW queue) Of course, if this way is choosen and is turning out to work out, later inclusion of the mpeg encoding stuff in mplayer must be discussed with ftp-master prior to it happening -- we (as in, Debian users in general) just get to have a chance of a slightly crippled mplayer in the archive in the meanwhile. I agree As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. a. From debdev Mon Sep 26 11:33:39 2005 Date: Mon, 26 Sep 2005 11:33:39 +0200 To: [EMAIL PROTECTED] Cc: Diego Biurrun [EMAIL PROTECTED], MJ Ray [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED], Joerg Jaspert [EMAIL PROTECTED], Jeroen van Wolffelaar [EMAIL PROTECTED] Subject: questions on mplayer Message-ID: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=nFreZHaLTZJo0R7j Content-Disposition: inline User-Agent: Mutt/1.5.9i Status: RO Content-Length: 2300 Lines: 64 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear ftp-masters,=20 (and in particular Jeroen van Wolffelaar and Joerg Jaspert, who have discussed the problem before), in April 2005, during a thread discussing inclusion of mplayer in Debian, at http://lists.debian.org/debian-devel/2005/04/msg00997.html J. van Wolffelaar expressed the opinion that nowadays the only issue still blocking acceptance of mplayer in Debian may be=20 the (*) presence of MPEG encoding software.=20 [(*) as a matter of fact, up to some time ago AFAIK mplayer was unable to encode MPEG stream; but I heard that they are working on it] J. van Wolffelaar also said though that We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. I would be very grateful if the ftp-masters team may finally decide what are the requirements so that mplayer be accepted into Debian; in doing so, they may want to read http://people.debian.org/~mjr/legal/mplayer.html where M J Ray summarizes and links many info. To fix ideas, I would need official (at least privately to us) answers to these questions: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? 2) (if yes) do we need to remove MPEG decoding stuff? 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) The above questions are somewhat urgent, since the current version of mplayer in NEW has a security bug, so I would love to prepare a new version, and I would love to prepare it to comply to any request by the ftp-masters, so that I may upload it into NEW for their review. a. --=20 Andrea Mennucc Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name=signature.asc Content-Description: Digital signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDN8Bz9B/tjjP8QKQRAmxfAJ9IJ686tgGjSRBIbqBqQaACm7OROwCdH94G ulHqI6eqYyiOis8K8mrKz/8= =6Wc/ -END PGP SIGNATURE- --nFreZHaLTZJo0R7j-- signature.asc Description: OpenPGP digital signature
Re: congratulations to our ftp-master team
actually, there was a response in Aug 2004, as in attachment A Mennucc wrote: The oldest upload of 'mplayer' that I still find in my harddisk was 'Wed Jul 23 10:44:54 2003' (see attachment) So 'mplayer' has been waiting in NEW queue for some response from ftp-masters for 876 days (at least) From [EMAIL PROTECTED] Mon Aug 16 00:54:00 2004 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from sns.it (mail.sns.it [192.167.206.31]) by tonelli (Postfix) with ESMTP id 68F2517601 for debian; Mon, 16 Aug 2004 00:54:00 +0200 (CEST) Received: from newraff.debian.org ([208.185.25.31] verified) by sns.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 20014347 for [EMAIL PROTECTED]; Mon, 16 Aug 2004 01:01:46 +0200 Received: from troup by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1BwTic-00016O-00; Sun, 15 Aug 2004 18:43:14 -0400 From: James Troup [EMAIL PROTECTED] To: A Mennucc1 [EMAIL PROTECTED], Dariush Pietrzak [EMAIL PROTECTED] X-Katie: lisa $Revision: 1.30 $ Cc: Debian Installer [EMAIL PROTECTED] Precedence: bulk Subject: mplayer_1.0.cvs20030324-1_i386.changes REJECTED Message-Id: [EMAIL PROTECTED] Sender: James Troup [EMAIL PROTECTED] Date: Sun, 15 Aug 2004 18:43:14 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on tonelli.sns.it X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=4.5 tests=AWL,BAYES_00 autolearn=ham version=2.63 Status: RO X-Status: A Content-Length: 299 Lines: 16 Hi, Sorry for the delay in processing this package. Please upload a version with a sane copyright file - the one currently in the package still just says GPL. -- James === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email.
Re: I did ask, Re: congratulations to our ftp-master team
On Mon, Dec 19, 2005 at 10:22:33AM +0100, A Mennucc wrote: Dear Jeroen and everybody, here attached is an email I sent in September. Yes, I did ask to ftp-masters clarifications about your proposal in http://lists.debian.org/debian-devel/2005/04/msg00997.html and never received a reply. Jeroen van Wolffelaar wrote: While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... yes, your memory failed :-) (you are in the CC of the attached email) Yes, and I got it via ftpmaster@ too. I indeed failed to answer this mail, and so did we as ftp-master team. I'm sorry for that, I do my best to reply to all mails that I can answer to, but september was an increadibly busy month for me. Only speaking for myself here, if you haven't recieved an answer for a month or so and you expected one, you're welcome to prod me via mail, repeating every month if needed, I don't mind that for genuine questions that are not written in an offensive way. I know it's not nice, but I get a lot of mail, and as time passes, chances decrease significantly I'll ever get around to replying old mail. Alternative ways to solve this like adding more hours to days have proven hard to implement. I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. (sorry my english fails me here) Basicly: Drop mpeg encoding from mplayer source package - definitely less problems getting through NEW. As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member Of course. This is what I have been waiting for. For 880 days, roughly. I suggest you upload stripping all the mpeg encoding stuff, pending answer to that difficult question. However, what you do, is your choice -- if you prefer to wait and are not planning to strip mpeg encoding support out of the source package, that's not something the ftp-master team will have any say on. To answer the questions from your mail of september: 1) can mplayer be included into Debian, possibly with some fixes, including removal of source from the mplayer...orig.tar.gz ? I'm not aware of any fundamental reason why mplayer couldn't be in Debian. 2) (if yes) do we need to remove MPEG decoding stuff? Encoding, I assume you mean. Unsure, as I explained above and in earlier mails. It's a very difficult question, and we don't have an answer on it yet. However, removing encoding stuff would bypass the main problem that we have with mplayer right now, and then the answer to this question can then be researched in parallel to an mplayer-with-only-mpeg-decoding being available from Debian. 3) what other problems should we fix ? (please read http://people.debian.org/~mjr/legal/mplayer.html to know what has been already fixed ) I don't know of any at this moment, but I also cannot promise there won't be any more problems that need fixing found between now and the package being checked in the NEW queue. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I did ask, Re: congratulations to our ftp-master team
On Mon, Dec 19, 2005 at 03:03:54PM +0100, Jeroen van Wolffelaar wrote: 2) (if yes) do we need to remove MPEG decoding stuff? Unsure, as I explained above and in earlier mails. It's a very difficult question, and we don't have an answer on it yet. It would be really helpful if someone would actually research a comprehensive answer on this. Note that This is the same as such-n-such other package isn't an answer -- it only indicates that other package may have problems too. Any such answer should include a summary of relevant patents, what countries they're valid for, what functionality is claimed, whether it does or doesn't appear to cover the software in question, and what the patent holder's attitude seems to be -- support free software, ignore the little people, prosecute anyone they can, or what. Last time I looked at this, the mplayer folks had their page blacked out with a comment to the effect of if Europe gets software patents, mplayer will be illegal; but Debian operates outside Europe in places that already have software patents, and Debian tries to avoid illegal software... At the time, I believe the Debian mplayer folks were saying ignore the upstream stuff, which isn't really very helpful. MJ Ray's page only mentions patents once, saying: There were problems with copyright and patents (according to this summary of the history). The summary linked just says ffmpeg made it in, so it must be okay. Please, someone go all groklaw on the issue already... Cheers, aj signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Sun, Dec 18, 2005 at 04:34:54PM +1100, Anand Kumria wrote: On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. 2875 + Dec 13 18:17 Debian Installer ( 0) irssi_0.8.10-1_multi.changes is NEW 2876 + Dec 13 23:48 Debian Installer ( 0) irssi_0.8.10-1_multi.changes ACCEPTED 5.5 hours for a package to make it through NEW. I think you owe some people an apology. - 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is NEW 10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJECTED How many hours is that, David? Yours is a rejection of a problematic package, David's isn't. Is it so strange that ftp-masters try to do a better job than I'm rejecting this, because I'm not entirely sure this is going to be allowed, but I don't have the time to investigate right now and doing so would take longer than 5 hours? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Yes, but that's a different conversation. Anand didn't say anything about getting a reason. The proposal was that packages be automatically rejected if no ftp-master approves it within two weeks. I don't understand how that helps anyone. You still don't get any explanation, and now there's not even a chance someone will find time to look at it. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Russ Allbery [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Russ Allbery [EMAIL PROTECTED] writes: Anand Kumria [EMAIL PROTECTED] writes: A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Why? It seems like, if that's the way that you want the world to work, you could already just pretend that this is the case. If your package has gone for more than two weeks, it seems to me like you could decide to treat it in all respects as if it had been rejected and just go on with your life. If it ends up getting accepted, you could orphan it, or decide to pick it up again. When the ftp masters reject a package, they say why it has been rejected as a rule. So at least that part can't be substituted for in this way. Yes, but that's a different conversation. Anand didn't say anything about getting a reason. The proposal was that packages be automatically rejected if no ftp-master approves it within two weeks. I don't understand how that helps anyone. You still don't get any explanation, and now there's not even a chance someone will find time to look at it. Oh, I was taking automatically rejected as a statement of the policy, not the mechanism. I was assuming that the rejections would still happen in the usual way. I agree that if they are mechanical, then they are pointless. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Jeroen van Wolffelaar wrote: I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? The encoding functionality is built into a separate binary; mencoder. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. 2875 + Dec 13 18:17 Debian Installer ( 0) irssi_0.8.10-1_multi.changes is NEW 2876 + Dec 13 23:48 Debian Installer ( 0) irssi_0.8.10-1_multi.changes ACCEPTED 5.5 hours for a package to make it through NEW. I think you owe some people an apology. - 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is NEW 10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJECTED How many hours is that, David? Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] wrote: On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote: 5.5 hours for a package to make it through NEW. I think you owe some people an apology. - 8126 T Oct 25 Debian Installe ( 46) xmovie_1.9.13-0_i386.changes is N= EW 10552 T Dec 14 Joerg Jaspert ( 23) xmovie_1.9.13-0_i386.changes REJ= ECTED How many hours is that, David? David's example is representative. Your one isn't. Of all the people to pick on in Debian, the ftp-masters aren't the obvious target. How about dealing with some more significant problems? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote: Anand Kumria [EMAIL PROTECTED] writes: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Guessing by the name alone I would say this is a patent issue like mplayer and therefore a problem package that is not likely to get resolved anytime soon. But that is just a guess. And it is an incorrect guess. xvidcap itself uses libraries already in Debian. But thanks for playing guess the mind of the ftp-masters. Was it fun? For non problem cases the NEW queue was never as fast as now so congratulation of improving the NEW queue so much already. Giving your past month performance I'm sure the few remaining issues can be resolved in time as well. Ignoring anything 2 weeks or newer I count only 7 packages. This is great. Maybe you are a fan of being left in limbo, or like the perverbial Schrödinger's cat, but even a bad process can benefit from assurances. A simple assurance that your package will be rejected from the NEW queue if no ftp-master approves it within 2 weeks would actually be a benefit. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- signature.asc Description: Digital signature
etch release plan (was Re: congratulations to our ftp-master team)
Hi, On Thursday 15 December 2005 18:06, A Mennucc wrote: In my opinion, considering that the release of etch is 15 months away, Please don't consider this :) No matter whether it's a lack of knowledge or disbelieving in the etch release plan (a la it's scheduled for december so it will become march anyway...), IMO this contributes a lot to the problems of releasing in time. So I will quote the release plan posted by Steve Langasek on d-d-a two month ago. And as I havent seen an update to this, I assume it's still valid and _doable_. Message-ID: [EMAIL PROTECTED] --begin quote [...] This is the timeline that we think will get us there: N-117 = Mon 30 Jul 06: freeze essential toolchain, kernels N-110 = Mon 7 Aug 06: freeze base, non-essential toolchain (including e.g. cdbs) N-105 = Mon 14 Aug 06: d-i RC [directly after base freeze] N-45 = Wed 18 Oct 06: general freeze [about 2 months after base freeze, d-i RC] N = Mon 4 Dec 06: release [1.5 months for the general freeze] We believe that one key to meeting these deadlines is letting maintainers know about them well in advance so that they can plan accordingly, so -- here we are. [...] ---end-quote- If you don't believe your goals are reachable, you won't reach them. (Because then you won't work on reaching them.) Of course those goals also have to be reachable, but I have seen no indication they aren't. regards, Holger pgpmsMFeuYIKw.pgp Description: PGP signature
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Guessing by the name alone I would say this is a patent issue like mplayer and therefore a problem package that is not likely to get resolved anytime soon. But that is just a guess. For non problem cases the NEW queue was never as fast as now so congratulation of improving the NEW queue so much already. Giving your past month performance I'm sure the few remaining issues can be resolved in time as well. Ignoring anything 2 weeks or newer I count only 7 packages. This is great. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Russ Allbery wrote: Assuming that what you say above is correct and FFMPEG is the only issue (and I have no reason to doubt you), And if it's not, it would be really nice if the ftpmasters let someone know. I agree that xvidcap and ffmpeg should be treated the same. However, that is not evidence that xvidcap should be in Debian -- it's evidence that they should be treated the same. Perhaps the correct thing to do is file an RC bug on ffmpeg and get it removed from the archives. I don't know. Correct. When one doesn't know, the right thing to do is frequently both not make the problem worse and not overreact, meaning leaving ffmpeg in the archive and xvidcap in NEW until the situation is clearly understood and resolved is quite reasonable. Of course, we do need to eventually actually get the situation resolved and come to a conclusion, after which either both should be in the archive or neither should. But the current situation of having one in the archive and one not during a hazy patent/license issue is *not* evidence of someone doing a bad job. It is evidence of an incomplete job, which I think everyone, including the ftp-masters, would agree with. Certainly. Well put. Of course, leaving the job incomplete for this long without any visible signs of progress may be evidence of a job not done. But what *is* evidence of a bad job is that there is one obvious improvement on the current situation which could have been made at any time without making matters any worse. Specifically, xvidcap can be packaged without the ffmpeg code, and if the ftpmasters requested that, I am sure that Javier would be happy to do that as an interim measure until this is sorted out. If the ffmpeg code is the only issue, then it should *not* be delaying xvidcap. If it isn't, then Javier should be told. -- Nathanael Nerode [EMAIL PROTECTED] (Instead, we front-load the flamewars and grudges in the interest of efficiency.) --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I think it would be nice if the reasons for long-standing packages hanging around in the NEW queue were documented publicly, but I do think in these cases the maintainers actually know the reasons. Well, you're right in the case of Christian Marillat (it's documented neatly in the ITP bug trail), but you're clearly wrong in the case of Javier. Javier has stated that he's just guessing why his package has been stalled and that he really isn't sure. I don't know about the others. -- Nathanael Nerode [EMAIL PROTECTED] Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
[Thaddeus H. Black] 3. If James' imperial rules are unacceptable to us, then the alternative is to change the person in James' position. It has been years since any other option was credible. We all know this. This means dismissing James from his fortified posts of Project power---and accepting the potential consequences of converting a powerful James from a difficult friend to a difficult foe. [Thomas Bushnell] It was my understanding that the new DPL would seriously consider this possibility. It seems to have been simply ignored instead. As usual. I assume the DPL has been working in the background to try to resolve this, as an public and open power struggle between the DPL and the people in key privileged positions would soon become very ugly, and affect the Debian project badly. How badly do you want the omelet? Are you willing to break the eggs, oven and the rest of the kitchen to get it? What do you expect would happen if the DPL team reassigned the privilege of for example ftpmaster, system administrator or key ring maintainer to other people? The new people would lack passwords, physical access and the cooperation of the original people. The current privileged people might refuse to acknowledge the delegation, and ignore the new people and the DPL. We could end up having to set up a separate infrastructure for use by the new teams, while the old teams keep the old ones, and in practice a forked Debian project where some people keep working with the original privileged people, and others work with the newly delegated privileged people. This, I believe, would be the consequences of an open and public power struggle between the DPL and the current key privileged people. I'm not sure it is a win for the Debian project on short nor long term. As the current people seem to be reasonable people, I believe it is better to start by discussing the issues and try to re-enforce the teams with new people to take some of the load off these overworked people and hopefully make sure we both get improved performance in the areas were the project is weak, and increase what I call the bus factor, aka how many people will have to be run over by a bus before the process stops. At the moment the bus factor is 1 or less for several key processes in Debian. I guess the first part of the solution is to get those in key privileged positions to realize that there is a problem. If they don't, all effort to solve the problem will be in vain. Next, one can start to discuss possible solutions, and try to work out how to implement one of them. As all people involved have lots of priority tasks on their hands, and I suspect the lack of transparency, redundancy and accountability is not seen as a high priority problem by the key privileged people in Debian, it will take a long time to get to a point where solutions become visible. (And do notice, I am not talking about James the person as if he was the problem or the only problem. I know James and most of the rest of the key privileged people in Debian (I do not know them all. :) as hard-working, overworked persons, and seriously believe they want and need help in finding a solution to these issues. Just getting rid of James might not solve anything, if he is replaced with the next well-meaning hard-working, overworked person. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Anand Kumria wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. don't be fooled by the web page. The oldest upload of 'mplayer' that I still find in my harddisk was 'Wed Jul 23 10:44:54 2003' (see attachment) So 'mplayer' has been waiting in NEW queue for some response from ftp-masters for 876 days (at least) a. u mplayer_0.90-1_i386.deb ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1.diff.gz ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90.orig.tar.gz ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1.dsc ftp-master.debian.org Wed Jul 23 10:44:54 2003 u mplayer_0.90-1_i386.changes ftp-master.debian.org Wed Jul 23 10:44:54 2003 s mplayer_0.90-1_i386.changes ftp-master.debian.org Wed Jul 23 10:44:54 2003
Re: congratulations to our ftp-master team
Jeroen van Wolffelaar wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html at that time, you wrote/ / /So, adding these two tentative conclusions together, it seems likely that if mplayer were demonstrated with reasonable certainty to be free of MPEG-encoding code, it would be acceptable for inclusion in main as far as the FTP-masters are concerned (note: We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. Don't take my words on too much value though, maybe stripping this won't be required after all, but in any case, if it isn't there, we don't need to think/discuss about it -- reinclusion of the encoding stuff can then later separately be discussed)./ I have indeed been waiting to know if /it's *required* to strip MPEG /ftp-master not responding, still waiting.. ftp-master not responding, still waitingftp-master not responding, still waiting.ftp-master not responding, still waiting.ftp-master not responding, still waitingftp-master not responding, still waiting a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Petter Reinholdtsen [EMAIL PROTECTED] writes: I assume the DPL has been working in the background to try to resolve this, as an public and open power struggle between the DPL and the people in key privileged positions would soon become very ugly, and affect the Debian project badly. How badly do you want the omelet? Are you willing to break the eggs, oven and the rest of the kitchen to get it? Oh, I want the omelet, but not at the cost of the kitchen. So if the DPL team have been working behind the scenes, that's great. I can only speak (and only did speak) of what seems to be the case, judging by the external appearances available. What do you expect would happen if the DPL team reassigned the privilege of for example ftpmaster, system administrator or key ring maintainer to other people? The new people would lack passwords, physical access and the cooperation of the original people. The current privileged people might refuse to acknowledge the delegation, and ignore the new people and the DPL. If there is a serious risk that these people would so blatantly disregard our constitution, then the coup has already happened, and we should either stop pretending that we are governed by a DPL and GRs and a Constitution, or we should oust the coup. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
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]
Re: congratulations to our ftp-master team
On 12/15/05, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: If there is a serious risk that these people would so blatantly disregard our constitution That certainly seems to be the case, judging from the discussion that followed Bdale's Structural Evolution Debconf5 talk[1] - here's a transcript of the relevant portion: Branden Robinson: One of the concerns that we've seen crop up periodically over the years is that we can refactor the project leadership as much as we like but it's not going to do a lot of good if not everybody feels like they are part of the governed. And there are areas in the Debian Project that are vested with authority that predates the constitution. I've spoken with some of these people (and they've made postings over the years) - and they're not comfortable exactly with the idea of, say, the possibility of a madman DPL, for example. And I'm not sure that these same historical roles will be any more comfortable with a different thing. You know: We've been doing this for ten years now. You can change the constitution, you can put a board in there, you can put a person in there... Do what you want, but in the end this work's still got to be done. There's no benefit to them in recognising... Bdale Garbee: So there're a couple of fundamental things that come to mind when we start talking about this. One is that I think organisational structure - good organisational structure - very rarely does anything to guarantee success, but if you get the wrong struture it really can impede progress and success. That's sort of one idea. And the other one is that - it's been my observation that, every time I personally have ended up in the situation where I've started to think I was indispensable (and believe me, it's happened at various times in my history) - when something finally forced me to realise that that wasn't true, things in general sort of picked up pace and moved better as a result. And so there is this sort of trade-off, I think, between motivating participation and how you actually sort of keep from getting stuck in a rut or something. So... I don't know that I have any more brilliant ideas than that. [1] http://meetings-archive.debian.net/pub/debian-meetings/2005/debconf5/mpeg/2005-07-16/08-Structural_Evolution-Bdale_Garbee.mpeg -- Andrew Saunders
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: Petter Reinholdtsen wrote: But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). One of the FTP masters (I forgot who) once said that the best way to help get mplayer into the archive would be to present an overview of the patent situation surrounding MPEG and the like. ffmpeg has such an overview in README.patents, which might serve as a good basis, as the core library code of mplayer, ffmpeg and xvidcap is identical. (libavcodec/libavformat) Yes, the core library is the same, that's why I wanted xvidcap to point to link against the one provided in ffmpeg's packages and repackage the source to remove the ffmpeg files, I *guess* mplayer could do likewise. Notice, in any case, that the xvidcap packages in NEW *don't* use ffmpeg, the source code is there: $ ldd /usr/bin/xvidcap libpthread.so.0 = /lib/libpthread.so.0 (0x40033000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40086000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0x400a4000) libz.so.1 = /usr/lib/libz.so.1 (0x400c9000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x400dd000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x400f2000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x40101000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x4010a000) libc.so.6 = /lib/libc.so.6 (0x40121000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x4023a000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x40289000) /lib/ld-linux.so.2 (0x4000) libm.so.6 = /lib/libm.so.6 (0x40354000) libdl.so.2 = /lib/libdl.so.2 (0x4037a000) Relevant changelog: * This source package will build gvidcap and provide at as a separate binary package. It does not provide yet support for ffmpeg, but will do in future versions. Either this fact has not been noticed by the FTP masters or they don't care and having the source code of ffmpeg there is sufficient for them to delay the package entrance in the archive (even if there are packages with the same source code already in the archive, i.e. avifile, and I don't see anybody trying to remove them because of patent issues). Regards Javier signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
A Mennucc [EMAIL PROTECTED] writes: 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 Once again, I think these latter have been addressed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
A Mennucc [EMAIL PROTECTED] writes: 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. People explained a long time ago why this isn't a good argument, and it's kind of frustrating to have people continually asking for a repeat of it. The existence of a package in Debian is not proof that the package is okay to distribute for Debian. We do actually make mistakes, including mistakenly allowing packages into Debian that turn out not to have distributable licenses. It happens all the time. Assuming that what you say above is correct and FFMPEG is the only issue (and I have no reason to doubt you), I agree that xvidcap and ffmpeg should be treated the same. However, that is not evidence that xvidcap should be in Debian -- it's evidence that they should be treated the same. Perhaps the correct thing to do is file an RC bug on ffmpeg and get it removed from the archives. I don't know. When one doesn't know, the right thing to do is frequently both not make the problem worse and not overreact, meaning leaving ffmpeg in the archive and xvidcap in NEW until the situation is clearly understood and resolved is quite reasonable. Of course, we do need to eventually actually get the situation resolved and come to a conclusion, after which either both should be in the archive or neither should. But the current situation of having one in the archive and one not during a hazy patent/license issue is *not* evidence of someone doing a bad job. It is evidence of an incomplete job, which I think everyone, including the ftp-masters, would agree with. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Thu, Dec 15, 2005 at 05:08:07PM -0800, Russ Allbery wrote: When one doesn't know, the right thing to do is frequently both not make the problem worse and not overreact, meaning leaving ffmpeg in the archive and xvidcap in NEW until the situation is clearly understood and resolved is quite reasonable. Of course, we do need to eventually actually get the situation resolved and come to a conclusion, after which either both should be in the archive or neither should. But the current situation of having one in the archive and one not during a hazy patent/license issue is *not* evidence of someone doing a bad job. It is evidence of an incomplete job, which I think everyone, including the ftp-masters, would agree with. Quite well put. I'm hoping to get a resolution on this matter in the not too distant future (no guarantees). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Thu, Dec 15, 2005 at 05:54:34PM +0100, A Mennucc wrote: Jeroen van Wolffelaar wrote: On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html at that time, you wrote/ / /So, adding these two tentative conclusions together, it seems likely that if mplayer were demonstrated with reasonable certainty to be free of MPEG-encoding code, it would be acceptable for inclusion in main as far as the FTP-masters are concerned (note: We're not (yet?) saying it's *required* to strip MPEG encoding stuff, but in my personal opinion, it seems likely that this is what it'll turn out to be. Don't take my words on too much value though, maybe stripping this won't be required after all, but in any case, if it isn't there, we don't need to think/discuss about it -- reinclusion of the encoding stuff can then later separately be discussed)./ I have indeed been waiting to know if /it's *required* to strip MPEG /ftp-master not responding, still waiting.. ftp-master not responding, still waitingftp-master not responding, still waiting.ftp-master not responding, still waiting.ftp-master not responding, still waitingftp-master not responding, still waiting While you indeed haven't got a later mail, you also didn't ask for one to the best of my knowledge (my memory isn't infallible, so I might be wrong, if so, I'm sorry, please correct me)... Anyway, status is still basicly the same. I'm wondering what bit of my last few lines in the quoted email were unclear. While I specifically noted that removing mpeg encoding stuff might or might not be required, I explicitely said that stripping it anyway will make the whole pondering on whether it can be in the (source) package at all moot for the question whether mpeg encoding would be legal to ship on ftp.debian.org. To the best of my knowledge, mpeg encoding stuff is nowhere near the core funcionality of mplayer anyway, isn't it? Of course, if this way is choosen and is turning out to work out, later inclusion of the mpeg encoding stuff in mplayer must be discussed with ftp-master prior to it happening -- we (as in, Debian users in general) just get to have a chance of a slightly crippled mplayer in the archive in the meanwhile. --Jeroen N.B.: As in all cases, final verdict on whether a package will pass NEW is made at the time it's sitting in NEW and being processed by an ftp-master team member -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On 12/14/05, Anand Kumria [EMAIL PROTECTED] wrote: [1]: As I write this 79 NEW packages, 85 total. With only four entries more than a month old I think it's doing fine, especially compared to other maintainers/teams that have bugs open months or years.
Re: congratulations to our ftp-master team
On Wed, 14 Dec 2005 11:25:03 +1100, Anand Kumria [EMAIL PROTECTED] wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. Acknowledged. Debian might have problems, but NEW queue processing surely isn't one of them (any more). I have had a new source package (as in completely new) approved on the day of first upload in the summer. No problem here. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 01:40:09AM +0100, Steinar H. Gunderson wrote: On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. ... In my entire involvement with Debian from the development side, I've never seen the NEW queue being processed as quickly as it is these days. It used to be irritating to me -- it isn't today. I don't know the details of the three longest-running packages, but I assume you asked an ftpmaster about those? It's a long story, I asked about it in the thread starting at http://lists.debian.org/debian-devel/2005/08/msg01510.html but got no final answer It *seems* [1] that ftp-master has its issues about software that *encodes* mpeg but not about software that decodes it. Either way it makes no sense to have a package in the queue for a year when the software (i.e. the source code) that makes it be problematic is readily available in other packages and that software can be used for both encoding and decoding [2] and there's no RC bug asking for their removal from the archive. Also, patent issues are not listed under the serious violations at http://ftp-master.debian.org/REJECT-FAQ.html So, who knows. Not that xvidcap is critical for me, but it is somewhat annoying to have it sitting there for no (declared) reason. Javier [1] Look at http://lists.debian.org/debian-devel/2005/08/msg01562.html although Joerg says he is not speaking for the team [2] ffmpeg, package description: multimedia player, server and *encoder* signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
Anand Kumria [EMAIL PROTECTED] writes: [...] As this post indicates, it isn't just the ftp-master team failing Debian. Yeah, some Debian Developers suck a lot. Hm. The ftp-team is quite good in comparision, I'd say. Marc -- BOFH #208: Your mail is being routed through Germany ... and they're censoring us. pgp9GxxYhB79z.pgp Description: PGP signature
Re: congratulations to our ftp-master team
On Wed, December 14, 2005 09:42, Javier Fernández-Sanguino Peña wrote: So, who knows. Not that xvidcap is critical for me, but it is somewhat annoying to have it sitting there for no (declared) reason. While I generally agree with the other posters that NEW queue handling is going very well, I can also understand that you're getting a bit frustrated when ftpmaster just keeps on delaying the decision on your package, to even over a year. It seems the queue is suffering from starvation: a lot of effort is put in approving new packages as soon as possible, but the difficult packages do not seem to make any progress. I think the most important problem that inspires many of the frustrated posts to debian-devel, is that people are just left uncertain. In this particular case: the FTP-master responsible doesn't make any decision (either approves or rejects). At least, that's the only thing that's visible. I take from Anands post that he hasn't been informed recently about any updates aswell. If there are still open problems, the best thing would be to communicate them as clearly as possible. Currently the NEW queue webpage just lists package, age and bugs closed. Why not add a comments section where the FTP-master can indicate what has to happen in order for it to be accepted? The only thing we have now is some postings to this list which are many months ago, and our own guesswork. If the problem is that the situation is just very complicated and needs time: I'd gladly accept for other packages to be queued for a couple of weeks longer on this point if that would mean that the top-3 packages are finally decided upon. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. 2875 + Dec 13 18:17 Debian Installer ( 0) irssi_0.8.10-1_multi.changes is NEW 2876 + Dec 13 23:48 Debian Installer ( 0) irssi_0.8.10-1_multi.changes ACCEPTED 5.5 hours for a package to make it through NEW. I think you owe some people an apology. (Oh and to who ever processed irssi, thank you. Was a nice surprise to wake up to. :) ) -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
[Marc Haber] Acknowledged. Debian might have problems, but NEW queue processing surely isn't one of them (any more). I agree that the NEW processing is working quite well these days, and is no longer the source of much frustration in debian. The ftp-masters are doing a great job processing new uploads in a timely fashion. :) But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). I believe the maintainer deserve a reply and an acceptance or rejection in a predictable and reasonable time frame. Waiting indefinitely is not acceptable, as the maintainer do not really know what is wrong with the packages. So I do not agree with your statement that there is no problem at all with NEW processing. But this problem is a minor one, compared to other problems in Debian, and compared to the problems with NEW processing earlier. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Petter Reinholdtsen wrote: But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). One of the FTP masters (I forgot who) once said that the best way to help get mplayer into the archive would be to present an overview of the patent situation surrounding MPEG and the like. ffmpeg has such an overview in README.patents, which might serve as a good basis, as the core library code of mplayer, ffmpeg and xvidcap is identical. (libavcodec/libavformat) Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Yes, ftpmaster is getting efficient at the routine processing. Congrats! Moritz Muehlenhoff wrote: Petter Reinholdtsen wrote: But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). Indeed, the unfortunate part is the uploads which appear to have been stalled in limbo. One of the FTP masters (I forgot who) once said that the best way to help get mplayer into the archive would be to present an overview of the patent situation surrounding MPEG and the like. ffmpeg has such an overview in README.patents, which might serve as a good basis, as the core library code of mplayer, ffmpeg and xvidcap is identical. (libavcodec/libavformat) Hmm, good idea. mplayer has had all of its long-standing copyright licensing problems dealt with in recent years and debian-legal would be sad to see that go to waste. It looks like the packagers of mplayer and xvidcap have not been notified of the potential problems with their packages, and *that* is disturbing. I'm sure Javier Fernandez-Sanguino Pen~a would be willing to do whatever's needed with xvidcap up to and including repackaging the upstream tarball and removing functionality, and I expect Dariush Pietrzak would do the same. But they haven't been *asked* to. In contrast, Christian Marillat has been asked to and didn't, and the exchange is a matter of record, so the same complaint cannot be made about the ftpmasters' recent behavior regarding rte. Communication from the ftp team regarding these packages would be very helpful, since debian-legal didn't see any copyright problems with them, and all the possibly-patent-encumbered code is already present in other packages in the archive, AFAICS. With regard to rte, the stated problem was the presence of the MPEG encoder -- could this be the problem with the other two? But exactly the same code is also present in the ffmpeg package in the archive already (and in fact any version in Debian would simply use the ffmpeg code from that package rather than using its own copy). So I'm not really sure what the problem is. Is there an unfiled serious bug in ffmpeg? Is there a difference between ffmpeg and the others which I don't know about (perhaps they *are* using their own copies?) Is the problem purely one of documentation, in which case the ffmpeg README.patents file would be sufficient to get such packages in? Do the ftpmasters need help from -legal? Which is it? Similarly, what's wrong with xmovie (1 month)? More importantly, has David Martinez Moreno been *told* what's wrong? (Given what I've heard about the state of the upstream source, I imagine that lots and lots of things could be wrong, but David should at least be told.) Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1 month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1 month); if there's something wrong with each of these packages, the packager should know by now. Maybe in some cases he does, but in others it appears clear that the packager doesn't know. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On 12/14/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1 month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1 month); if there's something wrong with each of these packages, the packager should know by now. Maybe in some cases he does, but in others it appears clear that the packager doesn't know. Shouldn't information like what's wrong be posted in public so others know too?
Re: congratulations to our ftp-master team
On Wed, 2005-12-14 at 13:35 +0100, Olaf van der Spek wrote: On 12/14/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1 month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1 month); if there's something wrong with each of these packages, the packager should know by now. Maybe in some cases he does, but in others it appears clear that the packager doesn't know. Shouldn't information like what's wrong be posted in public so others know too? My proposal would be exactly like that: extend the NEW queue information page with a comments field where FTP-master can add any comments for packages that aren't approved or rejected when first examined. It would just have to contain a quick note about the problems and what this package is waiting for. Thijs signature.asc Description: This is a digitally signed message part
Re: congratulations to our ftp-master team
Thijs Kinkhorst wrote: My proposal would be exactly like that: extend the NEW queue information page with a comments field where FTP-master can add any comments for packages that aren't approved or rejected when first examined. It would just have to contain a quick note about the problems and what this package is waiting for. Every ITP opens a bug, every upload stalled in NEW should close it. No need to extend anything, the BTS is where these comments belong, IMHO. -- .''`. Follow the white Rabbit - Ranty (and Lewis Carroll) : :' : `. `' Proudly running unstable Debian GNU/Linux `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, 2005-12-14 at 14:27 +0100, Amaya wrote: Every ITP opens a bug, every upload stalled in NEW should close it. No need to extend anything, the BTS is where these comments belong, IMHO. Packages can end up in NEW for other reasons, but for the cases that are currently the hot topic, that is indeed not relevant. I don't really care that much how it's implemented, as long as status updates are given. Thijs signature.asc Description: This is a digitally signed message part
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:08:52AM +0100, Moritz Muehlenhoff wrote: Petter Reinholdtsen wrote: But it is not doing a great job with processing a few old uploads. I consider it a problem that no decision have been taken on the few really old uploads (xvidcap, rte, mplayer). One of the FTP masters (I forgot who) once said that the best way to help get mplayer into the archive would be to present an overview of the patent situation surrounding MPEG and the like. ffmpeg has such an overview in README.patents, which might serve as a good basis, as the core library code of mplayer, ffmpeg and xvidcap is identical. (libavcodec/libavformat) That would have been me: http://lists.debian.org/debian-devel/2005/04/msg00997.html With the additional note that I now know the answer of [6], and iirc, it isn't even this thread, but an earlier one or two threads on the subject ago. Oh well. Mr. Ray has made an unofficial overview page at [1]. Anyway, there was no noteable response to my mail at all, specifically, I cannot remember any mail to myself or to ftpmaster with insights on the patent matter and/or efforts to simply drop it from mplayer (it seemed as if those were not really needed at all for its function? At least then the re-inclusion of it can be discussed later, while the less-controversion bits are in the archive...). --Jeroen [1] http://people.debian.org/~mjr/legal/mplayer.html -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thijs Kinkhorst wrote: I don't really care that much how it's implemented, as long as status updates are given. Sure :) -- .''`. Follow the white Rabbit - Ranty (and Lewis Carroll) : :' : `. `' Proudly running unstable Debian GNU/Linux `- www.amayita.com www.malapecora.com www.chicasduras.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thijs Kinkhorst wrote: If there are still open problems, the best thing would be to communicate them as clearly as possible. If James Troup and Ryan Murray have made one thing abundantly clear, it is this: as a general rule, they will not communicate. Not clearly, not consistently, not but rarely, not with the Project at large. James is not evil, nor presumably is the mysterious Ryan. They probably have their reasons. The infrastructure people who *do* communicate---Steve Langasek, A.J. Towns and Joerg Jaspert particularly come to mind---appear to value James' and Ryan's collaboration. Nevertheless, suggesting that James and Ryan themselves communicate is obviously a non-starter. How many years have we been suggesting this? Continuing to debate among ourselves how we wish James and Ryan would communicate is demeaning to us and, presumably, irritating to them. It stirs up loyal friends like Wouter Verhelst and accomplishes nothing. Unless James unexpectedly meets a vision of light on the road to Debian Damascus and mends his ways, the reality appears to be as follows. 1. Debian's infrastructure largely works rather well, probably in significant part because of the long volunteer hours James (and presumably the mysterious Ryan) devote to it. 2. Where Debian's infrastructure fails, we who want it fixed are required to play by James' rules: we must either work circumspectly through James' trusted lieutenants; or we must spend hundreds of hours hacking dak or whatever, proving our worthiness in the hope that James will someday let us join the Imperium's inner circle. 3. If James' imperial rules are unacceptable to us, then the alternative is to change the person in James' position. It has been years since any other option was credible. We all know this. This means dismissing James from his fortified posts of Project power---and accepting the potential consequences of converting a powerful James from a difficult friend to a difficult foe. I am just one insignificant DD. I do not flatter myself that my opinion counts for much (especially given my zero willingness to take over any of James' duties myself, and my zero credibility to do so, even were I willing). Nevertheless such as it is, I personally feel that despite good intentions James became a net liability to the Project years ago, and that the only good reason to retain him is that my hero Steve Langasek---who probably will spank me for writing these words---seems to want him. I really, really do not want to lose Steve, who is a bigger positive than James is a negative. Otherwise, the time had come for James to go, and the way to make him go were simply to thank him (sincerely) for his long service, to demand from him the relevant Project root passwords, and to dismiss him from his posts. And if, hypothetically, James would not peaceably turn over the root passwords? Aye, that's always the risk one runs in such revolutions, isn't it? That would hurt. Yet the very prospect of the danger is itself the sign that James has too much power. Still, even now, could James not change for the better? Probably, yes, he could. But after all these years the likelihood that he will is small, and at some point our continuing to beg him to change only unmasks us as fools. James is our J. Edgar Hoover: he is in some ways a good influence and in other ways a bad, but he does not want to change and he does not want to go, and you and I are going to have to face these facts. It has long been evident that further discussion with James on the matter is futile. Tolerate him, or dismiss him and face the the consequences; these are our choices. Your view may vary. Since I am not in the Imperium's inner circle, it would not surprise me if I had some of the details wrong, so detailed correction is welcome; but I think that the broad strokes of this post are right in any case. Perhaps you will agree. Thanks for reading. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED] [My preference is that this post not be reported in the DWN.] signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
Steinar H. Gunderson [EMAIL PROTECTED] writes: In my entire involvement with Debian from the development side, I've never seen the NEW queue being processed as quickly as it is these days. It used to be irritating to me -- it isn't today. I have the same feeling. I would rather give *genuine* congratulations to the ftp-master team, which seems to me to be doing an excellent job. I think it would be nice if the reasons for long-standing packages hanging around in the NEW queue were documented publicly, but I do think in these cases the maintainers actually know the reasons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thaddeus H. Black [EMAIL PROTECTED] writes: 3. If James' imperial rules are unacceptable to us, then the alternative is to change the person in James' position. It has been years since any other option was credible. We all know this. This means dismissing James from his fortified posts of Project power---and accepting the potential consequences of converting a powerful James from a difficult friend to a difficult foe. It was my understanding that the new DPL would seriously consider this possibility. It seems to have been simply ignored instead. As usual. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
congratulations to our ftp-master team
I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. Oh. http://squishy.cc/blog/?p=85 As this post indicates, it isn't just the ftp-master team failing Debian. http://wiki.debian.org/DPLTeamCurrentIssues From the current issues list, most infrastructure teams seems incapable of acting in any kind of reasonable timeframe. Either that or the high concentration of particularly reticient individuals is the problem. Something like that. Perhaps we should just recall the DPL, change the structure of Debian so it is an appointed board and appoint those already acting in a dictatorial manner to it. It'd be better to outline what current reality is rathing than continuing with our current charade. Thanks, Anand [1]: As I write this 79 NEW packages, 85 total. signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. ... In my entire involvement with Debian from the development side, I've never seen the NEW queue being processed as quickly as it is these days. It used to be irritating to me -- it isn't today. I don't know the details of the three longest-running packages, but I assume you asked an ftpmaster about those? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
[Anand Kumria's sarcastic criticism of the ftp-master team removed] On the contrary, it seems to me that the ftp-master team is doing a fantastic job and has been for many months. They have stayed on top of the flurry of NEW packages generated by two series of library renames from two separate C++ transitions, have generally kept the response times for most packages down to a good level, and have come forward with a list of most reasons for package rejection. Removal requests are also handled in a timely fashion. These are all vast improvements from not that long ago when NEW processing had pretty much stalled. I think the debian project owes much gratitude to the members of the ftp-master team whose job is vital to the smooth functioning of the project but who receive notice generally only when things aren't going well. The team works because people like Joerg Jaspert have come forward and just started helping when there was a need, and have continued to help in a job in which silence is considered a complement. I think that real, non-sarcastic congratulations are in order. I'm sure the appreciation I feel for the team is much more common among the developer community than the complaints of an irate user. It's also worth noting that constructive comments or actual help have a stronger track record of improving things than do sarcastic remarks. Either way, the original subject of the message was right on target! -- Jay Berkenbilt [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
* Anand Kumria [Wed, 14 Dec 2005 11:25:03 +1100]: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. Agreed. Thanks, Anand, for reflecting the feeling of (I believe) most developers in the project with such a short and concise message! Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Jacques Brel - La Fanette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Hello, On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote: I'd like to congratulate our ftp-master team on their ability to timely process packages progressing through the NEW queue. http://ftp-master.debian.org/new.html [1] I think you are an excellent example of people who are too busy for Debian. I must say that I am particularly impressed that you've managed to frustrate our users for over 1 year with the package 'xvidcap'. Truly the works of Gods among both Debian users _and_ Debian developers. If only more of the infrastructure teams displayed your attitude and dedication to volunteering for the benefit of all Debian users and developers. Strange, 4 NEW packages processed in less than a week for me. I think it is fast and not irritating. So, i really congratulate ftpmaster team. Regard Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Steinar H Gunderson [EMAIL PROTECTED] writes: I don't know the details of the three longest-running packages, but I assume you asked an ftpmaster about those? Patent issues around video codecs, discussed on debian-devel ad nauseam over the past few years. It would be nice to eventually get some resolution on this, but it's a known thorny licensing issue and isn't the easiest thing to work through. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 02:00:09AM +0100, Sylvain Le Gall wrote: Strange, 4 NEW packages processed in less than a week for me. I think it is fast and not irritating. So, i really congratulate ftpmaster team. AOL. Moreover, they really show interest in what is being uploaded and they care about looking at what is currently going in providing unvaluable feedback in many occasions! Thanks guys! -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: congratulations to our ftp-master team
On Wed, Dec 14, 2005 at 11:25:03AM +1100, Anand Kumria wrote: [1]: As I write this 79 NEW packages, 85 total. Then ftp-master must be really busy, since it's now 64, total 69. Also note that most of those packages in new aren't even a week in it, alot aren't even a day old. I think they're doing a really good job, even with the number of packages being so high because of the ongoing C++ transition. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
