Would like to volunteer for testing.
Moderator: Moderator Team
Would like to volunteer for testing.
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
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
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
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
Regards GreyGhost
*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.
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.
Would like to start testing real hardware..
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
Thanks,
Alan
Never mind... almost..
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
Thanks,
Alan
-
- Developer
- Posts: 509
- Joined: Mon Apr 25, 2005 12:46 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 ]
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 ]
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.
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.
-
- Posts: 282
- Joined: Thu Jan 04, 2007 12:43 am
- Location: Italy
An alternative method is:Haos wrote:For qemu (Qemu manager 4.0 for example) u just need to include this option: -serial file:debug.txt
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.
http://www.reactos.org/wiki/index.php/File_BugsI suppose now, that i must report it throught bugzilla. but i thought you wouldn't let anyone to just post a bug.
Everyone can submit bug reports to bugzilla. First try to search existing reports. Do not raise bug severity.
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?
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?
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.
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.
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 28 guests