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

Re: Maintainers, porters, and burden of porting



Lucas Nussbaum, le Mon 29 Aug 2011 16:49:17 +0200, a écrit :
> 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.

We want to avoid Not-For-Us. Maintainers should simply set the
architecture list.

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

Such common problems should ideally be documented.

Samuel


Reply to: