Le Thu, Nov 12, 2009 at 12:45:36PM +0100, Cyril Brulebois a écrit : > > 1. https://buildd.debian.org/build.cgi?pkg=udunits > 2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545653 > 3. https://buildd.debian.org/build.cgi?pkg=hdf-eos4 > 4. https://buildd.debian.org/build.cgi?pkg=hdf-eos5
Hi Cyril, What I see here in 1) and 4) is a maintainer who corrects his error in less than 10 days. In 3) he tried and lost momentum. None of these packages have been released in a previous stable release, nor they block any Testing transition. I think that what hurts you is the workload of reporting the FTBFS bugs. What if you don't? This information is obvious from the QA, PTS, and buildd pages. If there is no discussion to track nor patch to send, there is no need to open a bug, except for requesting the removal of the package if it stays in the limbo too long. This will also prevent to distract goodwill from fixing much more important RC bugs on packges already released in Stable, having higher Popcon scores and more complex dependancy tree. To me, the examples above are not a good reason to forbid source-only uploads when it will become technically trivial to enable them. Building the binary packages is and should stay the first (and not only) check before doing an upload. But there are situations, discussed on this list, where a source upload can be useful. Even without binary building before. That what the current binNMU system is doing anyway. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org