Re: [gpsd-dev] massive regression failures

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> 
> "Eric S. Raymond" <address@hidden> writes:
> 
> > That's good. Looking at paths is a bit ugly, but probably not as
> > brittle in general as looking a device major numbers.  I'd change the
> > test to do this on Linux, but the magic-number checks are time-tested
> > under Linux and I'm reluctant to disturb that code close to release.
> 
> That's fair enough for that case, but you might add a "this is not a
> good role model" comment :-)

Good idea.  Done.
 
> > How general are your paths to *BSD variants?  Could we use your code
> > for, say, Mac OS X?
> 
> OS X is semi-BSD and semi-Mach, with extra Apple gratuitous
> incompatabilities...
> 
> On OSX: It turns out /dev/ttyp and /dev/dtyp are present, though (with
> major 4/5 vs 5/6 on NetBSD), so including that if on OSX should help.
> PL2303 devices show up as /dev/tty.PL2303-[hexcrud]; the driver isn't
> built in.
> 
> I suspect that enabling what I wrote on normal BSDs (Free, Open, Dragon)
> as a starting place is probably better than not having it.

I'll do that.  Pushed...
 
> > An interesting question of method:  I could skip the delay if the device
> > type check returns source_unknown.  That means the test would fail safely
> > on platforms where sourcetype() doesn't work.  But...I think there's an
> > argument that it is better for this to fail noisily so people doing
> > ports will notice this and fix sourcetype().  Opinion?
> 
> Given that the delay is about energy consumption in some places, it
> seems better not to break on other places.

Actually, now that I look at the code with the last couple of changes,
I think we're in pretty good shape to let it break on any uncovered
cases. As in, there may no longer *be* any uncovered cases...

> Also, the regression tests failing due to the delay issue is a) a
> non-obvious syndrome and b) masks any other failures.  So I think you
> should instead add a test to check that sourcetype worked, somehow, and
> have that not break the rest of the tests, but just get reported.
> Essentially, I'm arguing that a single test failure pointing this out is
> fine, but failing 81/89 is not.   This is related to the fact that if
> any of the 89 tests fails, the rest of the tests don't get run, which of
> course is not about this change but it's convenient to rant about it
> now.

This is a good idea, but not a complication I want to get into before 3.12.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature