Eric Lavarde writes: > Hello, > > George Danchev wrote: > > * Generally, your sponsor(s) would want to test the packages, however > > that would need certain home automation infrastructure to be in place > > which is not available everywhere, so you might need to suggest a way to > > simulate their operation if that is easily possible. > > I'm not a DD but I would tend to reduce the problem to a nice-to-have > and not see it as a show-stopper: when I package a library, I'm pretty > sure that my sponsors don't check that they work, but only that they > compile properly and are in accordance with the Debian policy(ies).
Well, that might really depends across the sponsors, however, here are some points to consider: * people usually sponsor stuff they are using one way or another (example: I for one do not sponsor java packages, since I don't use them) * in the case of libraries, chances are that there might be examples to check some basic functionality the library provides or writing a really short app just to call some functions shouldn't be that involving anyway. And it is fairly easy since the library package is actually provided and ready to install/remove/whatever (example: yajl, stx-btree) * chances are that your sponsor actually uses that library with their own packages and/or in their own software (same examples apply) > Anyway, as maintainer, it's me receiving the bug reports, so I better > make sure that it works ;-) http://www.debian.org/doc/developers-reference/beyond-pkging.html#sponsoring Sponsoring a package also means accepting responsibility for it, and there are no reasons to believe that sponsored packages should convey less responsibility than sponsor's own packages. -- pub 4096R/0E4BD0AB <people.fccf.net/danchev/key pgp.mit.edu> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
