[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Maintainers, porters, and burden of porting

On 29/08/11 at 16:16 +0200, Bernd Zeimetz wrote:
> On 08/29/2011 01:06 PM, Lucas Nussbaum wrote:
> > On 29/08/11 at 09:47 +0200, Andreas Barth wrote:
> >> * Lucas Nussbaum (lucas@lucas-nussbaum.net) [110829 08:59]:
> >>> I'd like to reinforce the fact that it's the porters' responsibility 
> >>> to investigate porters issues, and propose the following
> >>> responsibilities:
> >>> (1) It is the responsibility of porters to:
> >>>     - track architecture-specific bugs (build failures, toolchain
> >>>       issues, etc)
> >>>     - investigate and solve such bugs
> >>
> >> 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)?
> 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.

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

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

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.

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

- Lucas

Reply to: