Le dimanche 10 janvier 2010 à 13:35 +0000, Graham Percival a écrit : > Yeah, but 80% of the time, that person is me. And I'm doing major > changes to the build system that could potentially screw up other > people. When major developers (be it John in relation to > translation stuff, Carl about new developers, or Han-Wen and Jan > about anything) point out problems in stuff I did a few months > ago, it really makes me stop and re-evaluate what I'm doing.
This is normal; even doing our best, some goals are so difficult or require an amount of work that is not compatible with the need of having something which is implemented quickly, so there's always a balance to be found between them. > I mean, I don't make a proposal unless I really think it's a good > idea, so when I don't hear any objections after a few weeks, I > assume that there were no objections because everybody else also > thought it was good. But empirical evidence now shows that this > isn't true, so I'm trying to find a way to discover these problems > earlier. I doubt there is such a way that will work all the time; there might be one if we were full-time developers, but even in this case we might oversight some drawbacks of a proposal and only discover them after its implementation. In our current situation, it's much worse, as I'm sure not all developers (at least I don't, mainly because I earn no money with it and I'm not enough addicted, available and skilled) look at each nitty-gritty detail of committed piece of code or makefile and its consequences. If a developer wants to require approval for a proposal, a patch submission is necessary; if he commits directly, there is some chance that it doesn't get checked by any other developers for a few months or years. I don't think that each commit to the build system should be submitted as a patch, but I highly recommend it for the new waf scripts; an equivalent way of submitting a patch is asking to look at a secondary branch (dev/*) then squash all commits of this branch into a single one with a good and detailed commit message. I especially insist on detailed commit messages for such important patches, which should demonstrate the committer knows exactly what he wants (i.e. what or which goal the added/changed code is supposed to achieve), and if he's motivated enough why he does it that way. Another thing that we could do instead of creating another list is writing down as a specification (even written quite informally) the important changes already started i.e. the i18n of Texinfo, stuff specific to building the website on lilypond.org (all details that are independent of the build system), and switching the build system. In each specification we should at least explain the desired goal, and we may specify the expected amount of work and the tools to be used. Draft specifications could be developed on the wiki or on the list; I'd prefer mainly on the wiki, discussion pages on the wiki being definitely usable for discussion, so this would not overload the list traffic. Specifications which are finalized and approved by all interested developers may then be added in the CG. Of course, all this may not be worth the extra work, but looking back at my very little development experience (especially LilyPond-related), I believe it's worth trying it. If there are no objections or better suggestions, I'm gonna start doing this for the translation infrastructure. Best, John
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
