Original link here.
Many interesting ideas on version numbering schemes. I like 2.11.X because it maps to years easily in people’s mind, but I look forward to seeing what is chosen. You guys break many of the rules for software development, so why not going backwards in version numbers
While you are talking about arbitrary numbers and new goals, I want to offer that you could consider a push towards zero bugs. In general, as long as your reliability monotonically increases (no regressions) that is an acceptable minimum approach because it means that you will never have a customer go from being happy to unhappy.
However, it is common in companies to make an effort to get towards zero bugs. Zero bugs is impossible, and that is a philosophical discussion. If you look through your current list of bugs, nearly every one looks scary to me and important to someone. You currently have 2,800 active bugs (http://bit.ly/LinuxBugs) The last time I looked, I found the median age was 10 months. In general, bugs should be fixed in the next release and so therefore 3 months.
Zero bug bounces is hard for the others because they don’t have sufficient resources. However, I believe you easily do. I can’t say that anything magical technically will happen if you work on your bugs faster, but I can say that people I respect as much as you taught me this. My salary was based on my ability to promptly respond to my bugs, and zero was everyone’s goal. Hitting zero, even for a minute, could be a newsworthy event, as another way Linux is better than the others. It also shows leadership to user mode. I sometimes get the feeling that many in the FOSS community look at bugs as something they could work on when they get bored of adding new features, instead of: “Holy poop, there is someone unhappy out there.”