2012/1/16 Carl Sorensen <[email protected]>: > I've been thinking more about the previous conversation about stable > releases and coordinating work. > > David seemed unhappy with the idea of a stable release happening once we > got to zero critical issues. My interpretation of his comments was that, > while zero critical issues may be a necessary condition for a stable > release, it is not a sufficient condition. Instead of having a stable > release be a byproduct, it should be planned for, and development adjusted > to make it happen. > > While GOP 9 said that we will treat all contributors as volunteers, and > not assign tasks, I don't think that precludes us from working together. > Somebody who identifies a strong vision can certainly rally volunteers to > the cause. > > So, with this idea in mind, I'd like to kick off a discussion about the > next stable release. Assuming that we can fix all the critical issues (I > think that's possible, but may be a month out or so), what else should we > plan to have part of the next stable?
>From a translator point of view, I wouldn't like having latest stable releases with translated documents from the previous stable release (or earlier). In other words, every stable release should have its own translated documents. The translation team needs time for that. So, I kindly ask, once again, for second minor stable versions in, say, two weeks' time, to be able to update as many manuals as possible in as many languages as possible. Later in this thread Graham says version numbers are cheap. Good, you have been following this policy until now, let's keep it. David asks for a status page for translations. It is in our web. > Is there something being worked on > and almost there such that we should wait for a stable release until it's > implemented? I don't mean translations should be stable-blocking. In fact, some translations are nearly abandoned. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
