On Fri, 2010-04-23 at 09:43 -0400, Kamil Paral wrote: > The Test Environment section tries to say that we are mainly > interested > in testing changes that would happen for users with fully updated > system, because that is the most common case and we can't simply test > all the possibilities. Good example is Package Sanity Test, where > we want to test upgrading from the most recent package in 'updates' > to the package coming to 'updates-testing'. We are not really > interested in upgrading from one package in 'updates-testing' to > another package in 'updates-testing', because that's not what's gonna > happen for most of our users. > > Of course some tests have a little different scope. Repo sanity > (the depcheck) tests repository contents rather than packages > on a system. That means that the third bullet point not really > applies to it. > > So it really depends on a particular test case, but I think generally > the idea of Test Environment should be valid as it is. > > Perhaps I wasn't clear. It seemed to me that when you were to test pending update A, you would setup your test environment such that it had a install of say F13, plus all the current stable updates of F13, then potential update A installed. What I'm saying, and what is more true to a user's experience, is that you need to install F13, plus all the current updates, plus all the pending updates, including A. When we push A, we won't be pushing it alone, we'll be pushing it with all the other pending updates at the same time, so that's the environment you need to test in. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
