Re: Maintainers, porters, and burden of porting

[Kurt Roeckx <kurt@roeckx.be>]

On Mon, Aug 29, 2011 at 01:06:15PM +0200, Lucas Nussbaum wrote:
> > 
> > Sorry, but I disagree here. I don't think it is reasonable to expect
> > porters to check for build failures in general, especially as many of
> > them just happen because of generic maintainer errors and
> > cross-architectures.
> 
> I'm not saying that porters should check for build failures in general.
> 
> If you take a list of packages that failed on $PORTER_ARCH, but built
> fine on at least two or three other architectures, do you really expect
> to get many false positives (i.e, non-arch-specific problems)?

I think to have a useful discussion we need to start with the
different kind of failures we can actually see that are arch
dependend.  Some of those shows up on only 1 or 2 arches, some
show up on all but 1 or 2 arches:
1) The source package just bails out because it never heard
   of that port, or needs to know that it's 32 or 64 bit, or
   that it's needs assembler, or it's just missing $arch in
   the control file somewhere, or has a broken configure script
   that checks the wrong thing, or whatever.
2) It has some undefined behaviour, it works on some arches
   and fails on others.  But it's not a problem with the port
   or toolchain.  But porters might know that those show up
   from time to time.
3) Packages that assume that some implementation defined behaviour
   is the same on all arches like that a char is signed on some
   ports and unsigned on others, that a size_t and long are the
   same size, that a pointer fits in an integer, ...  Some of
   those cause a compiler error or warning only on a few arches.
4) Packages that have arch specific code that does the wrong
   thing.
5) Packages where the author only uses Linux and are just not
   written with portability in mind.  This might include things
   like using Linux specific APIs and header files, using various
   extention without checking that they're available, not working
   on big endian machines, ...
6) Packages that have timing problems that only show up on some
   arches or buildds because they're faster or slower.
7) Packages that trigger arch specific toolchain, libc or kernel
   bugs.
8) Packages that themself work properly but use a library or
   program that has a problem.
9) Packages that trigger bugs in the virtualization software.

There are probably a few other categories I forget about.

It would be nice that we could detect as much as possible of those
problems.  And test suites help for that.  I think we need more
test suites, and run as much as possible of them at least during
the build process.

So what do you think should be the priority of the porters?

If you look at kfreebsd for instance you see that they didn't
build over 1000 source packages for various reasons.  And one
of the priorities to be able to get in the release is to build
as many as possible packages.  So I can understand that they
look at those packages and try to fix them, and maybe give
priority to those that are build dependencies for other
packages.  And I really think they could use help from the
maintainers there.

But they are probably also trying to make sure that it's actually
usable for what they want to use it, which might be that they
actually spend time on software not in any other port.

Then there are ports that basicly have good coverage and don't
have so many packages to deal with.  But the problem there is
that it's mostly not clear to porters what the problem might be,
and that if you file a bug that there is a problem with the
package people don't ask for help in trying to get it fixed.

If I see a testsuite error for a package I don't know, I spend
a whole lot of time trying to make sense of all kind of weird
things before I get to the point I know what the problem is.
It would clearly help that the maintainer helps me in getting
started how to debug this.


Kurt