zerozero is very correct. For about a year and a half, testing rolls normally, and for most of that time its stability is fairly consistent (whenever big new releases and package migrations happen, there can be problems, but there are consistently these problems
). I have heard that generally, after the release of squeeze the updates weren't too bad (although I don't think the people who were talking used gnome). However, there will be lots of leaps during this time period, so I would be very careful about upgrading. The linux kernel is due for an update (3.2 to whatever is in experimental - 3.6 or 3.7), and gnome will be updated to 3.6 (among many other updates). The gnome update will probably break cinnamon, so if you use that I would be careful. It's possible the cinnamon package from sid migrates to testing, and afterwards the maintainers rebuild this package for gnome 3.6, but I don't know if that will happen. Otherwise, testing is very stable towards the end of the freeze, because Debian is about to make a stable release, so none of the packages will have release critical bugs.
Otherwise, testing is fairly stable, but when a package breaks it can take a lot more time to fix than in sid. Packages migrate to testing from sid when they're 10 days old, have no known rc-critical bugs, have all of their dependencies satisfied, etc. If package foo 1.3.1 migrates to testing and a very big bug is found with it afterwards, the maintainer will fix this bug (or upstream will) and it will be updated in sid (let's say 1.3.2). However, someone could find a seperate rc-critical bug, which would cause the package to need to be updated again (now it might be 1.3.3). This means it would take at least 20 days, in addition to the time it takes for a dev to fix the bug, so lets say 30 days (5 days per bug, plus 20). However, what if sid has bar version 1.2, but testing has bar version 1.1. Package foo 1.3.3 depends on bar 1.2, but an rc-critical bug was found in bar 1.2. This could mean it would take a lot of time (2+ months) for foo to get updated in testing. If a big package has hundreds of dependencies, then you could imagine the possible problems.
You can kind of disregard the last paragraph, but I just figured that out after a while of thinking, so I wanted to write it down/share it
. Anyways, welcome to testing, and may the odds be ever in your favor
Dell XPS 15 l502x - Debian Testing 64-bit NetInst Xfce, SolydX 64-bit Debian Testing, SolydK 64-bit SolydXK Testing
Old Gateway Pentium 4 Desktop - Arch Linux 64-bit Xfce and SolydX 32-bit Sid