Package Update Acceptance Test Plan - final call

[Jesse Keating]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20100423/5e154575/attachment.bin