Re: ✘ Release blockers?

[Fred Wright]

On Mon, 30 Dec 2019, Gary E. Miller wrote:
> On Mon, 30 Dec 2019 19:42:29 -0800 (PST)
> Fred Wright <address@hidden> wrote:
>
> > On Thu, 26 Dec 2019, Gary E. Miller wrote:
> >
> > > Rather than goind around and around, changing the meaning of words,
> > > how about you show any problem that you think exists in one of the
> > > gpsd regressions.  Talking around a problem does not illuminate it,
> > > data does.
> >
> > This isn't about "regressions", it's about presenting incorrect
> > information to users in client programs.  Regression tests only prove
> > that the code does the same thing as it did before, regardless of
> > correctness. Regression tests are correctness agnostic.
>
> Yes, but you miss my point.  The issue you found was clearly in the
> regressions.  No need to talk about it, just show it in the existing
> data (regressions).
>
> > However, I've determined that the trouble in question was already
> > present in 3.19 and I just hadn't looked closely enough to notice, so
> > it's not a release blocker.
>
> Care to explain what you found?

The introduction of gnssid should have been an opportunity to clean up the 
whole PRN mess and actually report correct official PRNs (with "slots" 
playing the PRN role in the GLONASS case).  Instead it seems to be trying 
to report NMEA IDs as PRNs, and sometimes PRNs as "svids", which is a 
nonstandard and vendor-specific term.

> > I also spent some time chasing another problem that I thought was
> > new, but was actually just opportunistically behaving worse with the
> > new code, and the fix affects lots of regression tests, so I'm
> > putting off fixing that.
>
> Care to explain this too?  Maybe someone else can fix what you see?
> Is it a release blocker?

It's an old bug, where some computed error values only get set once and 
never changed, due to the way gpsd_error_model() and gps_merge_fix() 
interact.  I already have a fix that targets just epx, epy, epc, and eps, 
affecting 54 regression tests.  But there are almost certainly more values 
that need the same treatment.  It seemed better to put off that whole 
cleanup until after the release.

> > I did push a fix for a small problem I noticed while investigating,
> > as well as a tweak for xgps.
>
> Saw it, thanks.  You misunderstood the clearly vague comment that you
> changed, so I re-added the comment and improved on it.
>
> See if that now maikes sense to you.

Well, not specifying the basis for error values is pretty much par for the 
course. :-)

> > I've done the usual testing across a wide range of machines and VMs,
> > and it looks good to go.
>
> So no blockers?  Just two issues you don't care to share?

See above.  And "good to go" meant no blockers.

Fred Wright