Bzr development stopped

[Stephen J. Turnbull]

Martin Pool writes:

 > This is a really interesting point.  I think we were right to
 > generally want to have tests for all changes, considering the
 > importance of bzr being reliable, but it was also a barrier to
 > people getting their first change in.

Yeah, but not since the patch pilot.  You guys have done a *really*
good job of supporting new contributors, and you should be proud of
it.  The regular patch pilot reports were very useful too, both for us
bystanders to get a peek at your community service (which often is not
apparent to those on the periphery of the project even when you put
lots of effort into it!) and I expect in encouraging new contributors
to get started.  (I don't recall seeing any recently. :-(  Maybe that's
part of the reason for the recent lull in feature development?)

 > There was some feeling that just having an integration test is ugly
 > and bad for code health.  I see the point but you have to consider the
 > costs; for beginning patches I would rather have an integration test
 > than no fix or no test.

But for *submission*, you don't even require an integration test.
It's not that hard to get started, and the core contributors often
picked up the ball and ran with it even before the patch pilots.

If the bug is sufficiently important, you can relax the auxiliary
requirements like documentation and testing.  But testing is like
teaching.  If you can't do the "T" thing, you probably don't
understand the functionality well enough to put it in a mission-
critical app.

Steve