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

Re: Release sprint results - team changes, auto-rm and arch status

Daniel Pocock writes ("Re: Release sprint results - team changes, auto-rm and arch status"):
> I have had unusual issues on kFreeBSD with reSIProcate although that is
> partly because the unit tests are so exhaustive that they expose obscure
> bugs, e.g.
>   http://list.resiprocate.org/archive/resiprocate-devel/msg08488.html

I think this is a good example of the kind of bug that is sometimes
blamed on a port even though it probably isn't really a port-specific

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.  Debugging races in the field is very
difficult.  Much better to have them show up in a porter's build test,
than to have them show up later on users' machines.

So if anything, I think bugs like this one are an argument for keeping
kFreeBSD (and other minority ports) with as high a status as
practical; not an argument for throwing it out.

> It could be argued that the "cost" of these other architectures is not a
> one-sided equation - their presence contributes in some way to the
> overall quality of the software that people include in Debian.


>  So the net cost may be lower than people really think, but of
> course that doesn't take away the fact that it is a cost that has to
> be paid to keep these ports there.

We should be wary of setting the clearly visible and accountable costs
of keeping a port, up against the difficult to measure and mostly
invisible benefits in terms of reduced need to do in-the-field
diagnosis of obscure bugs (for us and our users).


Reply to: