Bzr development stopped

[Toshio Kuratomi]

On Wed, Sep 12, 2012 at 04:01:12PM +0900, Stephen J. Turnbull wrote:
> 
> I would suspect that the strict quality control is a bigger factor,
> combined with the usual issues of learning a complex code base that
> manages a complex set of data structures, plus strict review and test
> policies.  Even highly skilled developers need to put in a lot of time
> to get their patches through the queue, despite the wonderful "patch
> pilot" program.  I can't imagine users want quality control relaxed
> much, though (except for people who desperately need some feature, and
> even they would argue for a one-off I bet).
> 
Anecdotally only:
* I did have to ask my employer whether I could sign the Canonical
  Contributor Agreement but once permission was given I was able to do so
  and have been legally able to contribute
* My experience trying to contribute has matched Stephen's suspicion.
  There's a ton of things to learn and do when contributing to bzr compared
  to other projects.  Writing test cases, as he points out, are one of the
  areas with a learning curve.  I think the reason there is that patching
  a bug can be done by narrowing down the issue to a line of code,
  understanding the concepts in that line of code, modifying that line, and
  then checking that it solves the bug.  Writing a test case requires that
  you understand and setup enough of the surrounding environment to be able
  to run that line of code.  The line of code you are fixing might only
  involve knowing about filesystem paths but if the function containing it
  requires some sort of Bzr object or two when called, writing the testcase
  can be much harder than writing the patch to fix the issue.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120912/8e4614bf/attachment.pgp>