2012/1/3 David Kastrup <d...@gnu.org>: > I am afraid that we are painting ourselves into a corner. And I don't > think that we are doing ourselves a favor by defining "stable" as "a > random moment when somebody managed to get GUB to run for Windows and > OSX". We should define "stable" based on the stability and state of the > _actively_ happening development. _That's_ what we should be cutting > the stable branch from. And _then_ try getting it ported timely to the > platforms that have, lamentably, a rather lacklustre progress of > releasable material and platform-specific development. I see very > little correlation between what I'd call a measure of stability, and > what the current set of "Critical bugs" entails.
While this sounds reasonable, i'm not sure if a policy could be written that would reflect your intentions; they're a bit too vague. And even with current guidelines its always possible to say "i think that we shouldn't make a stable release despite having 0 critical issues, because current master is shabby and we have some major changes going in the codebase". I think that the problem may be that we don't organize our work (and don't want to according to GOP7 http://lilypond.org/~graham/gop/gop_7.html). In fact, we work quite like a bunch of individuals doing really independent things all the time; there are little to no efforts like "guys, let's fix that <and 5 people start collaborating on something>". Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel