Joseph Smidt wrote: > I know I am in for an argument, but I think it is a good > question. I'm sure many of you have read Mark's blog: > http://www.markshuttleworth.com/archives/56. It says 76% of Debian > users run unstable and probably a fair fraction of the rest run testing. Those numbers are apparently based on this survey: http://www.lucas-nussbaum.net/blog/?p=206 Which only examined 85 xchat users on #debian on oftc. The number combined testing and unstable FWIW. I wouldn't give it much credance. The version numbers from popcon are much more interesting, but also heavily skewed by eg, d-i defaulting to installing popcon in etch but not in (released versions of) sarge. One interesting thing I do see in the popcon numbers is that, even since a little before the release of sarge, the number of machines with its version of popcon installed has remained very close to the same, while the number using testing versions of popcon surpassed it even before d-i started installing it by default. I'm not sure that this indicates; manually installing popcon probably selects for the kind of users who use unstable/testing. It will be interesting to get the data from the next stable release where many people should install it by default. I do think that we probably have as many if not more users using testing+unstable than stable, but at this point that can only be a gut feeling, there aren't really good numbers to back it up. > I think Debian (I maintain a couple packages too, and hopefully more in > the future, so I am not just trying to tell those who work what to do) > should consider only supporting unstable and testing for a few reasons: If you're interested in Debian supporting unstable and testing and not stable, then there are several things you can do to help bring those distributions, especially testing, up to par as a really usable distribution for a larger percentage of users: * Participate in the testing security team, which can always use more help. * Help with d-i and with getting frequent releases of the installer out. * Help nudge those releases closer to being full releases of testing, rather than just being releases of the installer. * Help the release team deal with RC bugs that hold packages out of testing with other issues that block transitions, so that testing has current versions of software (and current security fixes, etc). Since all of these activities also have side effects that make stable releases better and/or more frequent, and most of the work done targeted at making stable releases better makes testing better in between, I've not worried much about trying to realign the project's focus away from stable. -- see shy jo
Attachment:
signature.asc
Description: Digital signature