On Thu, 2009-10-15 at 17:27 +0200, Kevin Kofler wrote: > Michael Schwendt wrote: > > If you know that you would _never_ be happy with a test-update becoming > > a stable update, then either don't push such a test-update or unpush > > it (manually or by relying on karma automatism). > > That was my point! > > > However, it could be that you would need to offer a test-update for two or > > more months before you would get essential feedback that helps with > > deciding whether it's safe to mark it stable or not. > > So we only disagree about the timelines. IMHO 2 or more months is way too > long. You should not need that much time to know whether the update is > broken or not! The big problem is that many months is almost > indistinguishible from "never" for all practical purposes. If you enabled > updates from testing, you're still stuck with no upgrade path unless you > stick with testing forever. The main advantage of putting strong time limits > on testing is to provide an upgrade path for one-time testers back to the > stable stream. 2 months is too long for user apps maybe, for X.org or Mesa from what I can see for ever probably isn't long enough, its not a matter of how much time something spends in updates-testing its a matter of how many people run what is in there and report on it. We get a lot of QA from the community on the run-in from Beta to GA, however we get nothing at all even close post-GA, so finding regressions post-GA is close to impossible without it hitting updates. you can get lots of +1s easily finding the -1 that matters is hard. Dave. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
