Re: [gpsd-dev] 3.13 has shipped

[Eric S. Raymond]

Hal Murray <address@hidden>:
> There is an overhead for each release, both for the developers and for the 
> downstream systems to pickup the new version, test it, and merge it into 
> their system.

That is true.  However, from a distro-builder's perspective GPSD is unusual
in some helpful ways:

1. We ship a good enough test suite that there's not a lot of point in
running tests beyond 'scons check' on the target platform.  What more
could they do, really? Short of sending someone outside with a laptop
and a GPS puck, not much. 

2. Our defect rate has been really low for a really long time.  Two
CVEs and three crash bugs, total, in 10 years.  I'm looking at the
tracker; since we moved to Savannah in 2011 our tracker has
accumulated a grand total of 74 bug reports most of which are really
code- and build-polishing requests; perhaps 5 could be classified as
genuine user-visible bugs, all minor. That's an incidence of a not
completely trivial bug once every six months or longer.

With those statistics, are the distros going to do anything but run
scons check and push the "go package" button when it doesn't barf?
Not if they're sane; their attention is better spent on software much
less armor-plated.

What I'm saying is the qualification procedure for GPSD new releases
is so cheap that I think we could quintuple our release frequency
without causing anyone a decision-overhead problem.

> With any change, there is the risk of introducing new bugs.  If your
> goal is stability and you are happy to do without new features in
> order to get better stability, then short release cycles aren't
> going to help anything.

I don't really feel like I have to plan for stability, per se.  The QA
policy (automated tests for everything we can, turn every bug report
into a test) does a good job of locking that in for us. 

What I want to do instead of planning for stability is *reduce the
risk of experimenting*.  That means paying even more information to
tests and fault scanners.

I liked the experience of writing two new features (TOFF and ntpmon) 
and pushing them out the door rapidly, with little fuss.  So much
more fun that six months of accumulating tiny changes with an
exhausting three- or four-week slog at the end.  Let's do
that again!

>        It might help to keep track of how many
> bugs have been reported for a particular release so you could
> identify the good ones.

It's a good idea in principle, but our defect incidence is so low
and sporadic that I don't think there's a signal there.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>