Joseph Rushton Wakeling <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
