Re: Maintainers, porters, and burden of porting

[Lucas Nussbaum <lucas@lucas-nussbaum.net>]

On 29/08/11 at 18:21 +0200, Bernd Zeimetz wrote:
> 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.

I think that bugs caused by important differences compared to other
Debian architectures are the porter's job to handle, not the
maintainer's.
That includes stuff like:
- missing/different packages on $ARCH
- missing/different libraries on $ARCH
- different libc semantics on $ARCH (hi kfreebsd+hurd!)
etc.

KFreeBSD is a very nice experiment, and the KFreeBSD porters are
amongst the most helpful I've been talking to. But if porting software to
KFreeBSD's linuxthreads-based threading library with slightly broken
semantics becomes my own task, I won't try to solve issues on KFreeBSD
and instead stop supporting it, because I just don't have the time to do
that.

> >> 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.

Only once you have pinpointed a specific problem. In my case, it often
means going from a broken Ruby script to a minimal test case in Ruby, to
Ruby's C code, to a minimal test case in C.

> >> 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'.

The porter should do the work become he cares about that architecture.
I'm perfectly fine with helping porters get my packages ported to the
architectures they care about. I'm not fine with having to spend a lot
of time porting my packages to 'experimental' ports.

Anyway, I'm just trying to see if we can find ways to work better
together, since all those ports are a very important feature of Debian.
But it doesn't sound easy...

- Lucas