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
bug.
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.
Exactly.
> 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).
Ian.
Reply to: