Re: update on binary upload restrictions
Steffen Moeller <steffen_moeller@gmx.de> writes:
> 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
> category.
>
> Steffen
Wanna-build gets (some of) the Build-Depends automatically set and the
package remains in Dep-Wait till they are available. There is also a
difference between a maybe-failed buildd log and the actual admin
setting the package to failed after checking. So "failed" has 2 levels
of certainty.
If the amount of failures is used as priority then even some wrong
results would only delay a package but not totaly stop it from being
build. There would be some (unjust) delay in a few cases but I highly
doubt anyone would mind much. The current system is much worse and
there hasn't been a GR about it yet.
MfG
Goswin
Reply to: