On 12/10/13 5:42 AM, "Mike Solomon" <m...@mikesolomon.org> wrote:
>Hey all, > >As 2.18 draws near, I¹d like to work with everyone to establish a system >of branching for LilyPond development. After several rounds of >discussing things with David K, this emerged as the best way to avoid >arguments about integrating work into the development branch that have >led several contributors, including myself, to significantly reduce time >on the project. I can see how the proposed mechanism avoids arguments about work that is going into individual developers branches, but I don't see how this avoids arguments about what goes into the development branch. As far as I can see, this proposal supports the creation of multiple forks of the lilypond development branch, one for each of the "privileged" developers, plus one for the accepted features. And then lilypond.org should support all of those forks. This seems like a nightmare to me. It is good for somebody who wants to get their features out the the user base. But this just makes the decisions about what to include in the development branch more emotionally charged. I'll present a hypothetical exchange between two caricatures: the creative developer who is only concerned about adding a really neat feature, and doesn't care how it affects the code base; and the consistent developer who is only concerned about the consistency of the code base, and would rather have no new features added than have a new feature added that requires contortions in the syntax, the parser/lexer, or the code base. Note that both of these are caricatures, drawn for the purpose of highlighting the conflict, not for the purpose of illustrating the behavior of any real developer. Creative developer: "See how many people like this feature? It's so positive that we absolutely have to include it." Consistent developer: "See how badly this would destroy the current code base? It's just an ugly hack. If we accept features like this, our code base will soon consist of nothing but ugly hacks. I don't care how many people like the feature; it's disastrous as currently implemented, so I won't accept it." And now, in addition to the different points of view of these developers, we have the added pressure of users clamoring for a feature. Personally, I want *both* the creative developer and the consistent developer to be satisfied. I want ugly hacks in the codebase to be decreasing, not increasing. I want new features that make the engraving better. If we can't implement new features without ugly hacks, I don't think they should be added to the codebase. But I don't want stasis in the codebase to prevent the addition of new features. Developers already have branches on the main repository. So this proposal is not really to add branches. The real issue in the proposal is about how to get users using these branches. I have a very hard time thinking that it's in the best interest of lilypond as a project to have multiple official development branches. Instead, I think that developers who create a branch that provides some new functionality should invite users to test the branch (which probably means that the developer needs to get GUB running on his or her branch and then make the binaries available). >[1] I feel that this reduction in commit diversity is the biggest >obstacle to LilyPond¹s future evolution, which is why I¹m calling on >everyone to make a concerted effort to think this through. I have made a concerted effort to think this through. I believe that a reduction in commit diversity is a serious problem. I think the community was greatly weakened when Mike felt that it was no longer worth putting up with the hassles to make his contributions. However, I think that a fractured development branch (up to 6 different branches) would be an even bigger obstacle to future evolution. I think it would lead to a balkanization of LilyPond. Of course, given my participation in development over the last couple of years, my input may not be worth much. Thanks, Carl S. _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
