On Thu, Nov 12, 2009 at 12:45:36PM +0100, Cyril Brulebois wrote: > Charles Plessy <ple...@debian.org> (12/11/2009): > Look at e.g. the history of non-buildability for Alastair McKinstry's > packages. udunits[1,2] comes to mind. (Note I don't think I'm a > carebear, but that I'm not that used to YELLING in bugreports. Until > then.) hdf-eos4[3] or hdf-eos5[4] are nice, too. Happened with other > packages, too. > > 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
To me the *interesting* part is *HOW* did the current policy of requiring binaries to accompany uploads address sloppiness with these uploads? The obvious answer is it did not. On the contrary, it allows questionably built packages into Sid potentially breaking other package's dependencies. Consider, 1. libfoofoo maintainer uploads with binary and new ABI for AMD64 2. libfoofoo FTBFS 3. ubberapp maintainer builds their app in pbuilder on AMD64 and uploads with high priority due to security fix 4. ubberapp now depends on questionable binary on AMD64 and buildd binary on rest of architectures. Can't migrate to testing. For source only upload, #2 would prevent #4 from occurring. Another followup is how source-only uploads would affect quantity of FTBFS? And if FTBFS would increase due to laziness of DD to actually compile packages, would this result in buildd machines' queues to increase so they are always behind? My guess is trivial FTBFS would not increase significantly except maybe for Arch:all. I would rather have source-only uploads and have some sort of automated script keep track of uploads and FTBFS. Use that as means of monitoring quality of work of DDs. If a DD for the last 10 uploads has 6 FTBFS then maybe it would be something that could be addressed as area of improvement or simply retiring from the project. > Note that _you_ started asserting things, _you_ should be presenting > facts to back it up. And if you really want a list of maintainers not You've got to stop with the rage in your replies. :) Cheers, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
