Ros-dev

ros-dev@reactos.org

1 participants
5793 discussions

Re: [ros-dev] [ros-diffs] [janderwald] 24590: - provide a sample configurat ion file - allow other address line resolver than addr2line
by Murphy, Ged (Bolton) 21 Oct '06

21 Oct '06

> +; > +; ROSBOOT_CMD > +; > +; This value is the command which is executed to gain debugging data > +; this value is mandatory > + > +ROSBOOT_CMD=D:\sysreg\qemu\qemu.exe -serial file:debug.log > -boot c -m 128 -L D:\sysreg\qemu\ D:\sysreg\qemu\RosVM.vmdk > -cdrom D:\Reactos\ReactOS-RegTest.iso Is there scope to add vmware to the test? Ged.

1 0

Re: [ros-dev] [ros-diffs] [janderwald] 24584: * beginning of a system regression tools
by Alex Ionescu 20 Oct '06

20 Oct '06

janderwald(a)svn.reactos.org wrote: > Author: janderwald > Date: Fri Oct 20 19:49:46 2006 > New Revision: 24584 > > URL: http://svn.reactos.org/svn/reactos?rev=24584&view=rev > Log: > * beginning of a system regression tools > Can this be done in C? C++ only slows down the build even more. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

2 1

Re: [ros-dev] Interested in the Testing Coordinator position
by Murphy, Ged (Bolton) 20 Oct '06

20 Oct '06

I hate ugly text formatting ... Resending in a (hopefully) readable format. Jerry wrote: > After a team says that it has fixed the bug ... <snip> > Each team may have mentees associated with it. The teams would then > help and guide their mentees in testing and coding, and these mentees > will help with the work load that the regular testers have. The goal > here is to guide the mentees to be regular developers and either stay > in testing or move on to other parts of the project and have. I'm a little confused with the idea of the testing teams fixing bugs. Testers aren't usually coders. It's great if they are as they can fix the bugs they find, but in general testing positions are filled by people who want to help the project, but aren't programmers. If a tester is a programmer too, I think you'll find that do a lot more programming than testing, as shown by our tree instability at the moment ;) Ged.

5 5

Re: [ros-dev] Interested in the Testing Coordinator position
by Murphy, Ged (Bolton) 20 Oct '06

20 Oct '06

Jerry wrote: > After a team says that it has fixed the bug ... <snip> > Each team may have mentees associated with it. The teams would then help > and guide their mentees in testing and coding, and these mentees will help > with the work load that the regular testers have. The goal here is to guide > the mentees to be regular developers and either stay in testing or move on to > other parts of the project and have. I'm a little confused with the idea of the testing teams fixing bugs. Testers aren't usually coders. It's great if they are as they can fix the bugs they find, but in general testing positions are filled by people who want to help the project, but aren't programmers. If a tester is a programmer too, I think you'll find that do a lot more programming than testing, as shown by our tree instability at the moment ;) Ged.

1 0

Interested in the Testing Coordinator position
by Jerry 20 Oct '06

20 Oct '06

Hi, I'm interested in the Testing Coordinator position. A few ideas I have for testing in general are, 1) One step update and compile 2) Divide and conquer testing. Testing would be divided up into teams. Each team will have its own leader. Each team will be assigned (or assign themselves) a mixed slate of verified unverified bugs. After a team says that it has fixed the bug or the bug is a false positive, another team will come and verify their findings. All this activity will be logged as it happens. 3) Testing Mentor Program Each team may have mentees associated with it. The teams would then help and guide their mentees in testing and coding, and these mentees will help with the work load that the regular testers have. The goal here is to guide the mentees to be regular developers and either stay in testing or move on to other parts of the project and have. The goal of this project is to grow the 4) I will try to listen and consider any ideas that other people have and try to work with people instead of against them. If you have any questions, be free to ask. I hope to be able to serve this project better.

1 0

Trunk stability
by Lucio Diaz 19 Oct '06

19 Oct '06

Even if i am not a developer in this proyect, may I give an advice? 1) You need two trunks, one experimental, the other 1 day old "booting trunk". 2)Your bot build the experimental trunk (you already have the build bot). 3) Once a day a "boot bot" would try boot the experimental trunk, if it is sucessful (i supouse, sending a "all ok" message throug com1) then it overwrithe the "booting trunk" with that experimental revision. 4)That way there is always a very recent trunk that is stable enough to boot, the testing is automatic, and you have quite narrowed the revisions with the problem. That way you could be working in a somewhat stable trunk, that can not be older than 1, 2 or 3 days if the experimental is failing. Best Regards, Lucio Diaz-Flores --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

4 3

Request w/ Bounty
by sn0n 19 Oct '06

19 Oct '06

Ok, please don't shoot me if this is 'to large a request' for what im offering, or to little. But here goes.. World of Warcraft on ReactOS, w/ NVidia Drivers AND guide complete to logging in and speaking with some NPC's (from what i understand the latest wine works well with WoW as far as right clicking, correct me if im wrong) Beings as i dont know how much work will be involved, what im offering is a copy of WoW to the DevTeam, (or you can use a 10 day trial free from Blizzard) and a $50/Bounty upfront. If this amount is to low, willing to go as far as $150/total, mind you i fall under the 'student' classification. Other then the mentioned, i would also like windowed mode to work (my preferred). And i use a NVidia Card. Thank you. -- ~Rob http://sn0n.com/

6 8

Re: [ros-dev] [ros-diffs] [jimtabor] 24553: Implement Get & Set batch limit.
by Alex Ionescu 18 Oct '06

18 Oct '06

jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Tue Oct 17 09:30:54 2006 > New Revision: 24553 > > URL: http://svn.reactos.org/svn/reactos?rev=24553&view=rev > Log: > Implement Get & Set batch limit. > > Modified: > trunk/reactos/dll/win32/gdi32/include/gdi32p.h > trunk/reactos/dll/win32/gdi32/misc/misc.c > trunk/reactos/dll/win32/gdi32/misc/stubs.c > > Modified: trunk/reactos/dll/win32/gdi32/include/gdi32p.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/gdi32/include/gd… > ============================================================================== Erm, shouldn't this be saved in the TEB? -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

2 1

[Fwd: Delivery Notification: Delivery has failed]
by Alex Ionescu 17 Oct '06

17 Oct '06

-- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

1 0

Trunk. Development. Testing.
by Aleksey Bragin 17 Oct '06

17 Oct '06

Hello, I have thought long time before writing this email, and finally it's time to write it... N.B. I don't intend to hurt or offense anyone in this email. And there is not so much use from a project leader who only says "yes", "good", "agreed". We all see ReactOS became quite a big thing. Big everywhere - source code, goals, development time... I think one would wish every FOSS project to gain that level and speed of development. If someone of you played Civ during youth, you certainly remember that your cities can't grow, grow and grow without any efforts - people become unhappy, city is ovecrowded, demanding sanitation and special facilities in order to continue growth. If you don't provide those needed facilities, the city is going to at least stop its development, and usually goes into disorder due to unhappines. Similar thing happens in software development too. Once project reached certain size (even in terms of SLOC), developers' "tools" should be upgraded and enhanced. That's it for theory. Let's have a look at ReactOS, and more specifically its trunk. I'm getting more and more complaints that trunk is unstable, remains unstable, and most of the time doesn't even boot, and the time came to actually solve this problem, once and for ever. As an example, I will show only one of common scenario: Some developer commits his code, which works for him on his, say, qemu but doesn't work for another dev on his real hardware. That developer continues to commit code, and in some time encounters that dev whose machine doesn't boot reactos and he says: "hey, you ...ng ...rd, you broke trunk!". I don't even dare to cite which reply follows, because it would take a few pages to quote. The developer who broke trunk starts to regress test, reverting revision by revision, spending time to identify the regressed revision (this may take a few days, and we don't have fulltime paid developers), and then finally finds the bug, fixes and commits. By that time, another developer commits code with a regression in other place, and trunk is still unbootable. And blaming continues, flamewars start, who broke what, instead of actually enjoying the development process. Pretty unproductive, yeah? And you, the reader, are definately wondering - what is the solution? I answer: There are a few solutions, but as always I will list only a few 1) "Wine"-method. There is one leader who decides what, how and when to commit. He maintains the tree, he makes sure tree is in good shape, he spends all of his time to do testing, merging, reverting, remerging. It works really good for Wine. Will it work good for us? I am in doubts, really. 2) Improving our current development system. That's the direction I would like to use. Major and the first improvement needed is testing. Testing often, testing early, automating testing, getting more people to test, regress test and feed results back to developers. Buildbot was a step in this direction, but more steps are needed. If someone broke booting, a proper recognized complain would be "Revision NNXXY regresses 3rd boot with a bugcheck code NN stack trace attached". The sooner this information is available and developer is notified - the faster this bug will be solved. If developer is inaccessible within a long period of time, a decision to revert this revision might be taken (that should be a really rare case). This shouldn't come to absurd of course, I can tolerate having trunk broken for a few hours certainly, when developer is working on a certain feature, and, well, of course he may mistake, not fully commit something and so forth. But having it half-broken for 2 weeks AND noone took time to regress test and find the guilty revision. Or yet another example, fortunately last for this email. I implemented an "alpha" version of usb mouse driver, along with that recently incorporated NT4 compatible usb driver. And assumed, and even asked in irc to test it - it's not that hard, but gives me a chance to fix not-so-obvious issues before it'll be enabled by default in trunk and will drive people crazy with some regress which I didn't see on my machine, and, at last, even hearing "yay, your usb mouse driver works!" just simply motivates me to finish e.g. a usb keyboard driver, find and fix bugs, etc. Conclusions. 1) To improve development quality we must improve testing. Automate, gather bigger testing team, etc. 2) Developers must be way more careful during commit. Just remember a simple rule: Trunk is not a wastebin where you dump code to. It's quite the opposite. Feedback. Your feedback is greatly encouraged and awaited. Feel free to discuss this in this ML. With the best regards, Aleksey Bragin ReactOS Project Coordinator

8 12

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev