On Wed, Dec 21, 2005 at 03:21:07PM +0100, Goswin von Brederlow wrote: > Anand Kumria <wildfire@progsoc.uts.edu.au> writes: > > > On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote: > >> Anand Kumria <wildfire@progsoc.uts.edu.au> 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 --"
Attachment:
signature.asc
Description: Digital signature