[ros-dev] Time has come, a call to developers

gedmurphy gedmurphy at gmail.com
Thu May 8 21:52:47 CEST 2008

I don't mean to sound harsh, but any dev should be able to fix bugs in most
parts of the OS without knowing how it works.
This is especially true in usermode, if a dev can't fix usermode bugs, then
they shouldn't have commit access in the first place.


-----Original Message-----
From: ros-dev-bounces at reactos.org [mailto:ros-dev-bounces at reactos.org] On
Behalf Of Heis Spiter
Sent: 08 May 2008 20:43
To: ReactOS Development List
Subject: Re: [ros-dev] Time has come, a call to developers


I mostly agree with the ideas developed in that mail. I've just a problem 
with one of them. Make bugfixing a priority before implementing new features

is a great idea; it could avoid some really bad releases such as ReactOS 
0.3.4. BUT asking people to learn how some Windows parts works in order to 
fix bugs is a bad idea. In my opinion, fixing bug is easier when the dev 
know code on which he is working especially when it looks like Win32k 
subsystem. Other way, it's easier to implement bug than fixing them...

So, we should focus our work on fixing bugs in branches of the OS we're 
working on usually and not trying to learn how something works to fix bug 
whereas there's a hundred times more skilled developer working on. We should

keep the "you work on what you like" motto.
I'd like also add something that always made uneasy. I don't know how you, 
others devs, are working, but I really don't understand why build can be 
broken after a patch. It should be tested (so build!) before being 
committed. Committing a patch that broke build shows a lack of tests and 
potentials bugs.

About "And if no beta this year, I'm sorry to say, but it may be too late.",

I'm afraid to say I agree. But we aim to make a WinXP OS like or WinXP is 
about to be retired by Microsoft to leave Vista taking his place. And in my 
opinion, copying  dead OS have no sense. So, indeed, we should hurry, and 
that leads to the last point I wanted to speak about. We don't have enough 
devs. Getting new and skilled ones should be really great for us... That's 
really hard to find!

Anyway, until 0.3.5 comes out, I'll try (as far as I can code) to fix bugs 
I'll find.

Aleksey, do not give up!

Best regards,
P. Schweitzer.

From: "Aleksey Bragin" <aleksey at reactos.org>
Sent: Thursday, May 08, 2008 3:46 PM
To: "ReactOS Development List" <ros-dev at reactos.org>
Subject: [ros-dev] Time has come, a call to developers

> Hello,
> this message is inspired by a lot of thinking, and yesterdays talk in
> #reactos, when Magnus Olsen's proposition to add support for more
> than one graphic adapter was a last drop into my cup of tolerancy.
> Thus I want to say, one very important idea. But what I want even
> more, for our developers to understand it. The key idea is that our
> work on the project now MUST be aimed at bugfixing, not at adding
> even more nice features. There are already quite enough of them
> (features)!
> As I said 1000 times, our general "users" don't care about ability to
> insert 3 graphic cards into their PC, and get ReactOS using them!
> They care about ReactOS crashing after closing regedit. Or during
> Office 2003 installation. And if it continues to crash this way, I'm
> sorry, but noone could feel the pleasure of multiple graphic cards
> support, or any other feature which is useless for 99% of potential
> users.
> Moreover, I don't understand why noone ever bothered to work through
> the winetests for reactos-specific parts of the system, like GDI,
> user32/win32k testing, kernel32 testing. There are lots of failures,
> and wine test results show APIs which are used for REAL, and by REAL
> applications, not some historic APIs implemented by Magnus (no
> offence, I'm just using him as an example, please excuse me if I
> sound harsh anywhere) which are unused by any real application nowadays.
> I clearly want to stress, that there is a strong misconcept in
> ReactOS way of development of its Win32 subsystem. There were a lot
> of positive events happening (win32k native tests library, great work
> by Timo at fixing various small issues, handles, memory leaks, etc).
> But it must be continued!
> Ged Murphy said very right about the problem: small problems prevent
> big apps from working. Wine already supports Office 2003 for years,
> and noone except me was trying to make support it better. The same
> applies to everywhere, there is no need to have some special skills
> to improve ReactOS. You know, there are not that many people who
> *really* worked on win32k in Microsoft, and they obviously can't code
> for us anyway, so everyone had to learn how to develop one or another
> part of the system. Look at Stefan Ginsberg - a guy who didn't know
> anything about C development 3 months ago, but learnt just by reading
> ros-diffs (well, and constant private messaging me in IRC asking
> questions, but that doesn't count), and yesterday spotted a couple of
> important real problems.
> Especially that counts for Win32-subsystem (the kernel must stay as
> strict NT-alike as legally possible, so it takes time to read all
> available literature), but for Win32-subsystem, just maintaining its
> code would result in a hundred less crashes now! I don't even say
> about rewriting bad written parts. Or just simply, very-very simply,
> syncing Wine's changes back into ReactOS!
> But nobody cares to do that.
> I especially delay the 0.3.5 release, because I want people to
> concentrate more on bugfixes. We could easily release in the
> beginning of may, there are enough of good changes for a usual
> reactos release. But I want this particular release to be *unusual*.
> If ReactOS wants to hit beta this year, developers must concentrate
> on a boring work first, believe me, there will be lots more fun when
> amount of people trying out reactos increases at least 100x.
> And if no beta this year, I'm sorry to say, but it may be too late.
> Thanks for thorough reading. Comments are welcome.
> With the best regards,
> Aleksey Bragin.
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list
Ros-dev at reactos.org

More information about the Ros-dev mailing list