Re: The horde of sloppy maintainers is a myth. Maybe not. Maybe yes.

[Adam Majer <adamm@zombino.com>]

On Thu, Nov 12, 2009 at 12:45:36PM +0100, Cyril Brulebois wrote:
> Charles Plessy <plessy@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