Jan Nieuwenhuizen <jann...@gnu.org> writes: > Graham Percival writes: > >> On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote: >>> - plain email-based patch submission using a benevolent dictator, >>> ie, use git the way it was designed and is still used by the >>> creators (linux, git). >> >> Are you volunteering to be that benevolent dictator? > > I'm sorry, not at this time. > >> Spend, say, 15 hours a week reviewing and approving patches? I have >> no quarrel if you want to do that. > > I do not share this assumption that this setup would cost time. What I > am suggesting is that this may help David and core developers if he > would take this up. I think that the continued success of Linux > is for a great part a result of this development setup. > > The dictator works closely only with one to three core developers > hardly bothers with the rest.
Well, you have obviously adjusted the numbers to fit LilyPond better than Linux, but that setup still calls for one to three core developers to filter every submission. Now I readily agree that my gut feeling about a patch definitely increases when I've seen Keith make it go through the works in a review. But there is just so much Keith to go around, and then it is not like he does not work on patches himself. Another problem with the dictator role is that he has the managerial, technical and human competence to deal with direct or at least indirect submissions in _all_ areas of the code. For me, much of the code base is inherited. I'm not actually qualified to give a blessing to code. Now if you take a look at the Linux processes, you'll find that Linus at least is _trusted_ to give an opinion for anything (and of course, since the Linux master is his personal repository where nobody else may write, he _is_ the ultimate arbiter). He delegates a lot, sure, but when this delegation of trust breaks his expectations, the fallout can easily make a developer go away. We don't have a lot of developers to start with. When Linus worked with a set of developers as small as the currently active LilyPond core team, he was much more friendly, forthcoming, open and helpful. His leadership style developed as a consequence of things going wrong and right, and adapted as the size of the project grew. Now look what a personality I'm starting with... > He does invest some time in getting those core developers to create > the kind of patches and code that he likes, so that after some time he > can pull their patches with hardly looking at them at all. And that > as a network all the way down. That ensures a very high level of > quality, while freeing up the people at the core. "All the way down" is a small way for LilyPond. And we don't have that many people to free "at the core". >> The whole system is set up to minimize the demands on main >> developers. Any solution which shifts the burden away from >> contributors and onto main developers is IMO bad for LilyPond. > > Of course. One fundamental difference is the kind of developer and/or helper the respective projects tend to attract. LilyPond is conceptually not that much simpler than an operating system kernel, but it's sexy to quite a different set of people. And making it usable requires different focus. Linux does not have anything remotely close to our documentation system, let alone translations, and it does not have a frontend and extension language. Basically, it's backend all around. Now we actually could use a _team_ of backend hackers which don't work on improving _what_ the backend does (that's what Gould and friends prescribe), but how one tells it how to do that, and how it picks the path from there. Because we have reached a state of fragile equilibrium where any additions require lots of care in order not to break conceptually unrelated stuff. That leads to half-done solutions like the skyline stuff: we have the ability to place staves closer now, and as a result, we now need _more_ pages for any given score. That's because the ability to place things closer necessitates more padding, and our page breaker only see the additional padding but not the ability to place staves closer. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
