On Mon, Jun 16, 2014 at 09:28:41PM +0200, Hans wrote: > Why not fix it directly in testing? I always thought, packages in testing are > already tested (for a time). Follwing your desription, it would be better, to > run sid than testing, as the fix is faster in sid, than in testing. Packages are not fixed in testing simply because they are not fixed in testing, they are fixed in sid and migrated to testing when they meet the migration criteria. Depending on your requirements, running sid may be a better option than running testing. If you are looking for bleeding edge (bear in mind it's called bleeding edge for a reason), and are comfortable with fixing breakages or can configure around breakage until it's fixed then sid may be the path to take. If you are looking to test the next stable-in-waiting, and are prepared to deal with breakages (which can, and do happen) taking longer to be (potentially) fixed than in sid then testing is the path to take. If you need a stable platform and stable feature set with little or no chance of the rug being pulled out from under you, then you want to go with stable. Cheers, Tom -- He who laughs last -- missed the punch line.
Attachment:
signature.asc
Description: Digital signature