Re: Doc build hanging (with memory leak?)

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> On 14/05/12 07:35, Graham Percival wrote:
>> On Mon, May 14, 2012 at 03:38:54AM +0200, Joseph Rushton Wakeling wrote:
>>> Here you go. :-)  Let me know if it needs tweaking or might be
>>> better in another section of the guide.
>>
>> Please see the "summary for experienced developers" in the CG.
>
> That really seems an astonishingly complicated procedure, especially
> when you compare to what is now the norm for DVCS-hosted software
> projects (i.e. upload to personal branch on code-hosting service;
> submit merge request).

We don't have a canonical developer, one whose personal
branch/repository would be official for the project.  We have automated
regression testing taking a _lot_ of computation time.  We have a
history of our canonical repository _breaking_.  We have a total dearth
of high-level developers, and a number of volunteers at lower level.

If you compare the complexity of the code base and infrastructure to the
available manpower and skill sets, the logical verdict is death by
bitrot.  The red tape is doing a surprisingly good job at keeping the
project from rusting in its tracks in spite of the large mismatch
between project complexity and active workers.  Partly because
sufficiently hardened red tape can be replaced by automatic procedures.

We have a fine-grained mesh of regression tests where _lots_ of stuff
gets caught before making it into the code base.

Yes, I have bursts of creativity where I bypass proper procedures for
well-chosen subsets of patches in order to avoid getting into a tangle
of diverging commits.  But that is an exception to the rule.  The "norm
for DVCS-hosted software projects" is commit first, question later.  We
don't have the amount of qualified cleanup personnel to deal with this
style.

And part of the problem is that LilyPond is monolithic rather than
modular, and opposed to the Linux kernel which is claimed to suffer from
the same condition, this does not just mean the memory/protection model
but means a _lot_ of centralized data structures without dedicated ways
of extension.  And that means merge conflicts as a regular consequence
of extending LilyPond, even along standard lines, making a decentralized
development style less workable.

Of course, some choices are also dictated by our tool chains: the review
system Rietveld is based on a centralized repository view, even though
it uses git internally for its working.

-- 
David Kastrup