Mike Solomon <m...@mikesolomon.org> writes: > On Nov 30, 2013, at 12:06 AM, Janek Warchoł <janek.lilyp...@gmail.com> wrote: > >> 2013/11/29 David Kastrup <d...@gnu.org>: >>> >>> But one person who just works on LilyPond can make a difference. Can we >>> keep this up? >> >> As you can see, it appears that David (d...@gnu.org) is doing abou >> as much as the rest of the development team combined!
Going by commits, it's more like 30-40%, and I tend to break issues into quite more commits than most contributors. So while I'm unsurprisingly the largest _single_ contributor (everybody else works mostly in his spare time), "as much as the rest of the development team combined" would be quite an exaggeration even if we talk just about committed lines of code. But that does not take into account a lot of other important work that is going on for keeping LilyPond alive. > I would argue that the point that Janek brings up above is not a > healthy sign for LilyPond development. Several developers, including > myself, have lowered their participation considerably over the past > two years. > > In my opinion, it would benefit LilyPond, and David too, if there were > more skilled volunteer developers working on the project. The main problem for letting skilled volunteers work effectively to the benefit of the project is the state LilyPond's code base is in. Then there are the tools, and the work dynamics. If you take a look at commit 7d3d28de0ce6e2f018aff599cecd944d1754fe3c Author: Mike Solomon <m...@apollinemike.com> Date: Thu Jan 10 08:54:12 2013 +0100 Makes all side-positioning based on skylines instead of boxes. via the tracker <URL:http://code.google.com/p/lilypond/issues/list?can=1&q=7d3d28de0ce6e2f018aff599cecd944d1754fe3c> then you'll find its core issue in 2.17.10, and followup problems in 2.17.15, 2.17.25, 2.17.26, 2.19.0. For one thing it means our reviews and the underlying infrastructure don't work out well when people apply them as they understand them. For another, it means that LilyPond's architecture is becoming increasingly fragile: improve one corner, and four distant corners crumble under unforeseen consequences. At some point of time we are running into an equilibrium where any change will cause a chain of repercussions that does not really die down in a sane amount of time. When we arrive there, more skilled volunteer developers working on the project don't really achieve more. The backend is a mess, with simple-closures, pure-unpure containers, cross-staff flags and other cryptic stuff with strange interactions that only few people can tamper with while causing only moderate damage to existing functionality. There are some subsystems which are surprisingly independently maintainable, like the MIDI system. But that partly also means that they are not actually well-integrated with LilyPond's data structures and concepts. The various output format backends don't make a whole lot of sense to me, but they are also somewhat independent. So there would be some room for people specializing on some things, and there is a lot that could be done even without messing with a whole lot of other things. A Cairo backend would be a mostly independent endeavor. Fast rendering interfaces would be mostly independent. Work on Emacs modes would be completely independent (Frescobaldi is a whole independent UI project). GUILEv2 migration is sorely needed, and would be a mostly independent project even though it touches quite a bit of code all over the place. It is clear that our development cycles have not worked out well. It's taken probably 9 months at least from the time we wanted to go for releasing 2.18 to now, and it has been frustrating to people. If we take a look at Linux development for comparison, the "merge window" for a new version is open two weeks, then it takes months to get to release quality. That's a linear development model at the core, but widely distributed code tested and merged in different combinations in a host of repositories. Nonlinear is, for example, GCC, where work commences on several branches but done mostly centralized. LilyPond is not modular enough to work well with the Linux methods where Linus Torvalds merges patches at an insane rate (he probably merges more patches on a hard work day than I produce in the whole year). Work in the GCC style where work is done on unstable branches only makes sense when people see their changes through to a state where they don't cause lots of problems, both as genuine bugs and more importantly as impediments to further development. We have basically the situation that a month of initial work comes with followup costs before a stable release is reached. That's more or less: month of documentation -> half a month of translation month of frontend work -> month of bug fixes month of backend work -> four months of bug fixes and so on, for different parts there is a different amount of followup work that is necessary. Working on several parallel branches without taking this into account will get us in the situation where the unstability just runs off and does not get back into releasability. Now the frontend ratio is where it is not really because of the fabulous state of it (though it is slowly improving) but rather because of a continually available expert with the tools and mechanisms used for it. The backend is much less coherent, so expertise is harder to acquire, people tend to work with partial knowledge, and progress is a lot more fragile. We need to get those four months down, and yes, a shouting match is not going to help. What will help is refactoring and rearchitecturing, and that needs people with a thorough programming background. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user