gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-dev] Thrashing on master


From: Eric S. Raymond
Subject: [gpsd-dev] Thrashing on master
Date: Sat, 7 Feb 2015 16:15:55 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Greg Troxel <address@hidden>:
> It would be really nice if all changes from now on were based on a solid
> understanding of what's going wrong.   Otherwise, gpsd seems to be
> reaching for the "most thrashing on master" award :-(

I think you seriously misunderstand my project philosophy.  I would probably
consider that award a complement for a job rightly done.

Experiments and false starts on the master branch - code instability
in general - is risky when you don't have confidence that you can 
both test the correctness of the code to very high confidence and
revert to a provably-good state at any time.

The way I run this project is a deliberate, conscious experiment in
what happens when you invert both premises.  That is, how should we
behave for maximum development efficiency when we *have* both high
confidence that we can test for correctness and the ability to revert
to a known-good state.

When you have these properties, trying lots of stuff on the trunk is a
way to maximize the volume and frequency of the corrective feedback
you get without seriously risking the health of the codebase. Because
the trunk is what people are *paying attention to!

I branch very seldom, and only when I'm trying something so
speculative that I'm not sure I want it to land on trunk at all.

We must be doing something right, as GPSD has an enviably low rate of
shipped defects by anyone's standards, let alone for a project of its
size and complexity.

This is not a strategy that would work for every project. It is
feasible because GPSD is very testable (in a way that projects with a
nontrivial user-facing interface generally are not).  That is, in
principle we can replicate the exact environment of most bugs with
confidence they will be reproducible.  Thus, time invested in test
frameworks like gpsfake.py has both a high expected payoff in theory
and high actual gains.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]