Re: ✘ Release blockers?

[Greg Troxel]

Bernd Zeimetz <address@hidden> writes:

> On 12/24/19 4:17 PM, Greg Troxel wrote:
>
>> I removed -o -t from SConstruct:
>> 
>> @@ -2268,7 +2268,7 @@ else:
>>      for gps_name, gps_log in zip(gps_names, gps_logs):
>>          gps_tests.append(Utility(
>>              'gps-regress-' + gps_name, gps_herald,
>> -            '$SRCDIR/regress-driver -q -o -t $REGRESSOPTS ' + gps_log))
>> +            '$SRCDIR/regress-driver -q $REGRESSOPTS ' + gps_log))
>>      gps_regress = env.Alias('gps-regress', gps_tests)
>>  
>>      # Run the passthrough log in all transport modes for better coverage
>> 
>> and am rerunning.  (I'm not sure if that's right, and what the
>> recommended way to switch between tcp and pty for input is.)
>> This also had a faliuer, but it looks like the usual too-low-WRITE_PAD
>> type.
>
> -o -t uses tcp
> -o -u uses udp
> no -o at all -> pty.
>
> There is no option in gpsfake to force pty usage.

So, with tcp:

  WRITE_PAD=0.004       fails reliably overall, but on different tests.
  WRITE_PAD=0.01        1 run of 1 total succeeded

I have recently seen Hal's "infinite loop" writing problem, leading to
an 8G result file.  I think that's tcp and WRITE_PAD 0.



At this point I am inclined to bump WRITE_PAD to 0.01 for NetBSD and
then declare that I am happy to release what we have.   Tests will be a
little slow (took 17 minutes that way), but slow is not a real problem
compared to false alarms and especially 8G files.

Gary: feel free to change WRITE_PAD to 0.01 in the netbsd case and
release, if everyone else is happy.   Otherwise, tell me if you think
making that change is reasonable, and I can do it and push the commit.

I realize many people are busy today and tomorrow :-)   I think it's
totally fine for all to ignore gpsd and pick it up again later in the
week.