Re: Release sprint results - team changes, auto-rm and arch status
On 29/11/13 18:23, Simon McVittie wrote:
> On 29/11/13 16:36, Ian Jackson wrote:
>> It seems likely to me that that bug is, at root, a race of some kind.
>> And it just so happens that the race is lost on kFreeBSD - sometimes.
>>
>> Detecting such a race is valuable to the project; it's certainly not a
>> disbenefit. After all, a race that happens to us sometimes is likely
>> to happen to users sometimes.
>
> Yes, to a point. On the other hand, each RC architecture where
> build-time tests are fatal inflates some subset of "ordinary bugs" to
> Severity:serious - if we'd seen this bug (or a similar "sometimes-fails"
> bug) "in real life", even if there's a way to reproduce it on (say) x86
> Linux, would it necessarily have RC severity?
>
> Perhaps this particular bug would - I have no idea how often it happens,
> or what functionality it breaks - but Daniel's phrasing implied that
> this particular regression test suite is far more thorough than what
> we'd consider to be "a major effect on the usability of a package"
> (Severity:important).
>
The test suite is executed on every upload and if it isn't 100%
successful the build fails and the package does not propagate on any
platform.
This race condition is 100% reproducible on the porter boxes too, I'm
yet to find the root cause though. Of particular note, it only occurs
on some of the more recent builds, so it appears to have been introduced
by some upstream change in the last 6 months.
Reply to: