Would like to volunteer for testing.

grip · Post by **grip** » Wed Mar 14, 2007 8:24 pm

Hi,
I've been watching this project for over a year. I should have some free time coming up so I'd like to help out. I'm a developer by trade but would like to get a feel for things by testing first. I have all kinds of hardware and software that I can test. I'd appreciate it if someone could point me in the right direction to start. A priority list of what to test would be nice too. I'll try to put a list of what I have together but it will take a while.
Thanks,
Alan

GreyGhost · Post by **GreyGhost** » Wed Mar 14, 2007 8:34 pm

Hello grip .. good to know that ur interested in testing ..
Lets get started .. THere have been recent problems with real hardware compatibility .. where man different hardware support broke and is slowly being fixed.. so i cant guarantee that all the hardaware will work but always good to have a nice report as to what worksand what not

Now .. ATM there is no proper priority list as such would be good to have one though.. but heres how u get staarted (in case u cant test on real hardware read the part bout QEMU ) or VMware if u want .. from here...
http://www.reactos.org/wiki/index.php/HOWTO

If u decide to get involved in TRUNK testing u may have to build the iso from soure urself or get the prebuilt isos ..
Then get the apps in and start testing

Also u may want to read these
http://www.reactos.org/wiki/index.php/Testing_ReactOS

and if u plan to do debugging ,
http://www.reactos.org/wiki/index.php/Debugging

Hope this helps

Post by **Z98** » Wed Mar 14, 2007 8:58 pm

*bangs head on desk*

Do not have the bloody time...............

Sorry. Setting up a list of things to test and etc is on my todo list. I just took care of the website translation issue but this one is a bit tougher. I've been talking with Wax, our previous testing coordinator, but he can't find some of the tests he conducted. Setting up a proper testing procedure is going to take us a while.

grip · Post by **grip** » Fri Mar 23, 2007 12:14 am

I figure that testing hardware and drivers would be a good start. Would it be better to load ReactOS directly onto a system and test or to run VMware? I would be testing ethernet cards, video cards, motherboards (chipsets), I/O cards, IDE cards, etc. Loading directly would be quicker but I'm not sure if I could get any pertinent debug information if I run into trouble. Also, I do have motherboards and CPU's down to 386's. I even have 286's and 8086's but I'm going to guess that the project is sticking to 32 bits or higher. What CPU's is the project expecting to support? Let me know.
Thanks,
Alan

grip · Post by **grip** » Fri Mar 23, 2007 12:26 am

I read the docs you sent me links to. It still wasn't clear whether a compiled ReactOS with debug mode would be better than virtuallizing. If I compile with debug and load the machine directly and output to a serial port, I could monitor it from another pc and that might be worth something. What do you think? Would this give us some kind of advantage over virtualization?
Thanks,
Alan

Post by **ThePhysicist** » Fri Mar 30, 2007 10:36 pm

If I have understood it correctly, you want to know if it's better to run ROS on real Hw to get debug output. You can also get debug output on a virtual machine. Just use a dbg iso or compile with DBG=1.
I don't know how that works on qemu, but on VMWare (Workstation or Server) you can install a serial port wich outputs the debugdata either to a file or to a named pipe.
I formerly used file output, because I didn't have a program that would display the output from a named pipe. IIRC, there's a tool (I think there are in fact 2 programs for win and linux) that forwards a named pipe to network, so you can connect with telnet. But I have just written a tool, that can directly connect to a named pipe and displays the debug output instantly. I am currently trying to get keyboard input to the pipe working, so you can also use KDBG. But that is pretty hard to test, as I am only using ROS debug output and it's hard to get ROS to crash, so that KDBG starts. Reminds me of Fireball trying to produce a BSOD on his presentation, but it just wont work

Here are 2 screenshots:
[ external image ]
[ external image ]

Nande · Post by **Nande** » Sat Mar 31, 2007 9:26 am

hello,
i just found about react os, and i like the idea, and i think you are doing pretty well.
I'm not a very good programer, neither i have too much time, but i'd like to help doing some testing.
but i don't know how are u organized to do this. can anyone tell me ?
i mean, what should i do?

Post by **hto** » Sat Mar 31, 2007 2:30 pm

what should i do?

Read this topic.

Post by **Haos** » Sat Mar 31, 2007 3:24 pm

For qemu (Qemu manager 4.0 for example) u just need to include this option: -serial file:debug.txt

instead of debug.txt u can use any filename. The file with debug output will be created in your Qemu\Media directory.

Nande · Post by **Nande** » Tue Apr 03, 2007 4:25 am

thanks a lot "hto", i've already readed that topic but still didn't understood what exactly should i do if i found a bug.

I suppose now, that i must report it throught bugzilla. but i thought you wouldn't let anyone to just post a bug. sorry, i'm really new at this community.

My best wishes to ReactOs.

Carlo Bramix · Post by **Carlo Bramix** » Tue Apr 03, 2007 11:10 am

Haos wrote:For qemu (Qemu manager 4.0 for example) u just need to include this option: -serial file:debug.txt

An alternative method is:
1) install COM0COM utility:
http://sourceforge.net/projects/com0com/
2) Assign the first virtual com to QEMU
3) Open the second virtual com with a terminal programme (hyperterminal, teraterm, etc).

Now you will have the same feeling when you debug with two different PC.

Sincerely,

Carlo Bramini.

Post by **hto** » Tue Apr 03, 2007 11:49 am

I suppose now, that i must report it throught bugzilla. but i thought you wouldn't let anyone to just post a bug.

http://www.reactos.org/wiki/index.php/File_Bugs

Everyone can submit bug reports to bugzilla. First try to search existing reports. Do not raise bug severity.

Mrkaras · Post by **Mrkaras** » Tue Apr 03, 2007 12:33 pm

bug reports don't directly effect reactos code so they are safe to be open for all to submit bugs. if you write new code the patch needs to be submitted in a bug report, you can not directly contribute the code unless you are a developer, that way, if you did try to break things whatever developer handled the bugzilla report would simply reject it before it did any damage.

I think the severity is normally set by somebody such as a developer ,unless you have a very good reason to set it your self leave it on the default setting. I think setting it lower is OK?

Nande · Post by **Nande** » Tue Apr 03, 2007 5:45 pm

Carlo Bramix:
I liked the Com0Com

Thanks hto.

Mrkaras:
i'm not correcting u, but as i send a bug, i had to set the severity of the problem, either way, i'm sure that when a developer takes that problem he will judge the real severity it has.

Post by **hto** » Wed Apr 04, 2007 12:36 am

Hi,

About severities:

http://www.reactos.org/wiki/index.php/R ... Severities

Do not use "blocker" or "critical" severity unless someone from dev team says it should be so.

Do not report several bugs as one, use different bugzilla entries for each bug.

If you're testing 0.3.1 release, it is worth to test also recent svn builds (from http://svn.reactos.org/iso/ ), many bugs was fixed (and new ones was introduced

)

If you're testing on real hardware, try to test also in virtual machine.

Would like to volunteer for testing.

Would like to volunteer for testing.

Would like to start testing real hardware..

Never mind... almost..

Who is online