Richard Campbell schrieb:
Hi Guys,
...
First Issue: Moving Target
...
This sounds like a good way to make life harder for everyone ;-)
Branches are a pain in the ass.
I also think that Incompatibilities due to moving target are a no-issue atm.
We have a lot of other more important issues to solve:
Bad design, bugs in existing implementations, missing implementations etc.
The only time I had a problem with the moving target was when trying to
load a wine-dll on windows XP, which failed, because it was using Vista
only api. But that's wine code.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
Both of these are very bad practices. Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list. For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.
I agree on that. But afair we only add app hacks to releases to make
reactos look more shiny than it is.
If you know of other examples, please point out where, so we can fix it
and slap someone... ;)
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework.
I have started a testing framework. It's for gdi32/user32
and win32k so
far. I am going to add win32k kenel mode tests soon.
And we accept patches.
Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN.
Oh, do you know how many APIs there
are? ntoskrnl alone has more than
1500 exports.
And how many tests are you going to write? :-P
If we all write tests,
This will help identify bugs in ROS vs Windows. Low level tests are
ESPECIALLY needed. Our driver compatibility currently sucks, and it's
getting worse every day. Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.
It might especially help to find regressions faster and automatically.
Might be an idea to get more people involved in writing tests.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in
userland. This process should be avoided. All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc. This goes back to the second issue.
Can you specify this a little more?
We use a few ros specific system calls in gdi32 and user32, and these
shall go away eventually. But that needs time.
I don't know of any other location where we use "ReactOS specific kernel
mode code in userland".