Hi, i said that i'll post an answer to this thread, so here it is :)
David and Graham are clearly speaking from two different points of view. Or, to be (hopefully) more accurate, they are on two orthogonal planes. David is an experienced developer. He can judge LilyPond code better than many of us; no set of rules is necessary for him to determine if LilyPond is, for example, ready for a stable release. Thus, he is worried when he sees us /too strictly/ following suboptimal rules - he knows when we should make an exception. This point of view is important, because it's the policies that should serve LilyPond - not the other way round. Graham's focus is on transparent /rules/ that are easy to follow, and preferably won't lay *too* much responsibility on Release Manager's shoulders. And, above all, won't require the Release Manager to be an expert programmer. This is important, too, because Graham won't always be the Project Manager. It's also not guaranteed that there'll always be an experienced developer with sufficient time to handle release tasks. I think that we need to find an intersection of these two planes: a system that is flexible enough to not restrict the project (allow common sense) and at the same time doesn't require expert knowledge and is self-regulating. I think that my suggestion from GOP2: 2 thread (http://lists.gnu.org/archive/html/lilypond-devel/2012-07/msg00245.html) meets these criteria: it has reasonable "default mode" and decent flexibility. I hope it will help :) cheers, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel