Hi,
Well, my roadmap would look quite different. You said the kernel had it's own one, but I'm not sure how to divide that.
First I'd like to point out some random things:
* ReactOS isn't usable for *anything* atm. It doesn't matter whether app x or app y runs, while the whole OS is unstable, not even taskmgr works properly and everythings is fubar once the system has crashed a single time, which still happens pretty often.
* I wouldn't mind if most apps crashed with a nice screen telling the user that he had bad luck and then everything would continue normally. But instead it's more normal that stuff freezes and the whole OS gets unusable. Our failure recovery is very bad.
* Our operative range is zero. ReactOS is not usable as a desktop OS, it's not usable as a server, it's not usable to play games or as a thin client or even to compile itself. Maybe we should find at least one thing that reactos can do properly.
* Our development model is based on fun. And it will stay that way. We all do it for the fun. If there is no fun, we won't be doing it. So trying to force people doing something is a bad idea. You can only try to motivate them. (Unless you have a shitload of money to dispense ;-))
* All developers have their own area of expertise / interest. You can ask me to work on file systems and I might be highly motivated to do so, but it wouldn't be of any benefit, because I know nothing about file system drivers.
Now my roadmap would look like this:
1.) Analyze the development process, find flaws and address them, optimize the process as much as possible. (Builtbot, regtests, branches, file layout, etc.)
2.) Put some effort into areas that affect the development itself. (Crashes, freezes, can't kill processes with taskmgr, can't restart explorer, registry corruption on crashes, failure recovery, debuggers, etc)
3.) Do a "market analysis". What are possible areas of application, what can we do right now? What's missing exactly? What do "customers" need?
4.) Get a usable release out, even if it's only usable for a very limited number of applications, but at least works good with those.
You might notice that while the previous roadmap looks like a 5-year-plan, mine has a much shorter time frame.
My 2 cents, Timo
Aleksey Bragin wrote:
Hello,yesterday we had a usual rant in #reactos-dev regarding organization, teaming and development issues, and I explained how I see it. I think explaining and discussing here would be beneficial.
I won't spend your time explaining how I came to this roadmap, I will go right to it. This roadmap is mainly usage-oriented and doesn't cover the kernel (it has its own one).
- Finish wine-based subsystem ("arwinss"), fixing all internal (absent
in Wine and/or trunk) bugs. Milestone 1: user32 and gdi32 known to work and support at least all the apps listed in the Wine app compat database.
- Test as many as possible apps known to work in Wine and determine
those which fail.
- Fix failing components (kernel32, ntdll, kernel, CSR, non-synced
DLLs, etc). Milestone 2: ReactOS supporting quite wide amount of applications, including major apps like MS Office suites, Open Office, CAD systems, Adobe products. Decision point: Because other Win32 components are proven to work, NT-alike user32, gdi32 and win32k development may be boosted, testing simplified.
- Implement filesystem drivers, using fastfat_new as a universal
skeleton for FS drivers. Use ntfs3g library and that skeleton to develop an NTFS IFS driver. Milestone 3: ReactOS with NTFS support (quite important for end users, thus separated into a standalone milestone).
- Total rewrite of networking, using NT's one as a model.
Milestone 4: ReactOS with a rock-stable networking. Ability to host database servers, web and FTP servers.
- Release 1.0 and profit ;)
So that's what I'm sticking to so far. I don't expect everyone to agree, but if more people are involved, achieving these milestones will happen faster. Also, they don't really have to go in a sequence, all of that may be done simulteneously (e.g. filesystem drivers must be developed against Windows 2003; kernel32 and ntdll could be fixed first using winetests without waiting for arwinss to be complete; networking could be again tested in existing ReactOS and Windows).
Comments, improvements are welcome.
WBR, Aleksey Bragin.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev