Jeffrey Altman <[EMAIL PROTECTED]> wrote: > Christopher D. Clausen wrote: > >> I file bug reports (although I haven't had any service crashes >> recently.) Everything I filed against the Windows client (and >> possibly the Solaris server, but still testing) seems to be fixed in >> the latest fc. > > Chris, you are one of the rare few who do test the Windows releases > and file bug reports. It is good to know that the issues you have > come across have been fixed. The problem that I am trying to address > is how do I know that (a) previous issues have been fixed; (b) that > new ones were not created; and (c) that existing ones simply have not > been reported. > > If I fail to receive a bug report from you, does that mean that: > > (a) you have tested the build and that all is good > > (b) you have not tested the build at all > > (c) you have not tested the build on a platform that would > experience a problem
Oh, so I should email the list with something like: "testing 1.5.0702 on Windows 2003 SP2. No problems encountered so far." ? > I am imagining something a bit more formal. In fact, speaking of web > design work, perhaps what we need is a web form checklist that can be > easily filled out as a report. > > * OpenAFS release > > * OS platform > > * Hardware architecture > > * A list of tests to perform with success and failure options. > If a test fails, then a text field for inputing a description > of the failure. > > If there was another page that could be dynamically updated so people > could see what combinations of <OpenAFS release, OS, architecture> > had been tested, then people could jump in to fill in the gaps. Yeah, some sort of list of things to check would be useful. >> I can (and have been trying to as often as possible) test clients on >> Windows 2003 Server (SP1 and SP2 beta x86) as they are released. I >> do not currently have any 64-bit OSes running nor do I have any >> machines running Windows XP or Windows 2000. If no one else has the >> time, I can setup test systems in a VM and make sure a basic install >> works, but I would not be actively using software in these VMs. I >> would assume that testing in actual environments would be preferable. > > Testing in actual environments would be preferable in some cases. > However, VMs are certainly nice for the ability to perform snapshots. > Especially when you want to be able to test the behavior of a clean > install. Would it be possible to get access to the automated testing framework? I'm almost sure such tests could be run in VMs as well. Or is this not needed b/c others are already running such tests? >> Also, I typically use the Windows cmd prompt myself and don't notice >> GUI issues (which is why I didn't notice that the explorer extention >> was broken until a week ago. Its been broken on my installs for >> several months.) > > If there was an item on a checklist that asked "Does the AFS Shell > Extension menu appear for XXX?" would you test it for each release? Yes. It would probably be best if someone else wrote up the checklist though. <<CDC -- Christopher D. Clausen [EMAIL PROTECTED] SysAdmin
smime.p7s
Description: S/MIME cryptographic signature
