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

Re: update on binary upload restrictions

On Monday 29 January 2007 10:42:25 Goswin von Brederlow wrote:
> Santiago Vila <sanvila@unex.es> writes:
> > On Sun, 28 Jan 2007, Benjamin Seidenberg wrote:
> >> If we do go to source-only uploads, could this problem be avoided by
> >> having arm and other slow arches wait until at least one other arch
> >> successfully builds the package?
> >
> > I think that would be a good idea anyway, even if we do not go to
> > source-only uploads. There is no point in wasting expensive CPU cycles
> > to build a package if it FTBFS on every architecture.
> I would rather do the opposite. Stop building a package when it fails
> on other archs. Thing about the (unlikely) situation that arm is
> idle. Nothing to build. Now someone uploads foobar. Should we wait or
> just try? If it works we saved time. If it fails only idleing is lost.
> Even better would be to take the number of architectures
> failed/succeeded/needs-build into account when deciding on the
> priority of a package. The more archs fail the lower a source drops in
> needs-build, the more succeed the higher it rises. The more backlog a
> port has the more successfull this priority would be, i.e. it works
> best for the problematic archs that need it.

We need to distinguish between the multiple reasons for potential failures, 
though. I do not know about the latest developments of the build daemon, so 
maybe my example is now outdated, but a failure because of missing build 
dependencies should not be punished since the package may be fine per se. 
Problems with available memory, disk space etc would fall under the same 


Attachment: pgpqOq52nSXRU.pgp
Description: PGP signature

Reply to: