On 08/29/2011 04:49 PM, Lucas Nussbaum wrote: [...] >> In my experience you would get a lot of issues which are nothing porters >> need to solve, like libraries not being available as the hardware just >> doesn't exist for that architecture > > Those packages should be set Not-For-Us anyway, no? So they still need > an action from porters or buildd maintainers.
No, for example zbar ships an example application which uses a webcam to read barcodes and the necessary webcam libraries are (or were!?) not available on freebsd and hurd - so only the build of that single example had to be disabled while recognizing barcodes from images works well of course and the library builds fine. >> or test suites failing for various random reasons. > > Like what? In my experience rebuilding the archive on amd64, there are > only a handful of packages where the test suite fails randomly. If it > fails randomly only on $PORTER_ARCH, it's likely to be an indication of > a bug in toolchain/libc/kernel/whatever that only triggers through a > race condition. And that's clearly porter's business. Doesn't make me wonder. I guess most software is well tested on amd64 and i386. >> If you want a help from a porter, > > As a maintainer, I don't want to be in a situation where I need help > from porters. I would like porters to feel responsible for packages on > their architectures. Of course, if porters want help from me, I will do > my best to help them. But it shouldn't work the other way around. Imho it can only work the other way round or we need a LOT more porters, and that won't happen. > I'm also completely tired of investigating issues which are already > known to porters, which is unavoidable if each maintainer is asked to > first do the investigation and then ask porters for help. I'm sure there are issues where even porters can't tell you its a known one without a lot of debugging. Also there is google which is very helpful in finding problems on weird architectures. >> imho you should present a problem in a way which is easy reproducible >> - I don't think that we should expect from porters that they debug >> your program's test suite for you. > > Note that failed builds are usually easily reproducible. Just try to > build the package. It fails. Reducing the failure to a minimal test case > usually takes hours of hard work, which are often useless, because when > you finally share the test case with the porters' list, a porter usually > says "oh, that must be $COMMON_PROBLEM_WITH_PORT". If a failed build is easy reproducible, where is the problem for a maintainer to come up with something easy to reprouce for a porter? Anf when it is not easy reproducible or some easy way to create a test case is not obviously - why should a porter do the work if you as maintainer probably know the source times better than the porter and you should be able to come up with something useful to debug much faster? We don't have enough porters to throw all the longish tasks on them, imho the maintainer should go to porters with an arch specific problem to solve, not with 'fix my package'. -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5bbc9a.8010...@bzed.de
