Tree Cleanup

[Alex Ionescu]

Hi all,

After talking to some developers about the recent state of the ReactOS
tree, compiler times and disk space, I've analyzed our tree and found
the following preliminary round of changes that should be made to stay
in line with our policy that ReactOS provides what Windows does, at the
core level. Any extra functionality or applications not provided by
Windows have always been supposed to go into rosapps, as well as test
applications. For testing/regression testing, I actually recommend the
creation of a ros-tests repository, which will contain the tests in
rosapps plus the ones I've mentionned below.

This isn't just about disk space or compiling speed, but also to keep
our tree clean and conformant.

Here's the list:

\base\applications\devmgmt should go into a new folder called "mscutils"
along with similar MSC clones.
\base\applications\getfirefox should be removed.
\base\applications\devmgr should be removed.
\base\applications\downloader should be moved to rosapps.
\base\applications\gettype should be moved to rosapps.
\base\applications\ibrowser should be removed.
\base\applications\imagesoft shoudl be moved to rosapps.
\base\applications\network\roshttpd should be moved to rosapps.
\base\applications\reporterror should be removed.
\base\applications\screenshot should be moved to rosapps.
\base\applications\servman should go into a new folder called "mscutils"
along with similar MSC clones.
\base\applications\shutdown should go to \cmdutils.
\base\applications\sm should be removed.
\base\applications\testsets should go to rosapps.
\base\applications\utils should go to rosapps.
\base\applications\winefiel should to rosapps.
\base\services\dhcpd should go to rosapps.
\drivers\base\debugout should be removed.
\drivers\base\green should go to rosapps.
\drivers\base\ramdrv should go to rosapps.
\drivers\base\test should go to rosapps.
\drivers\filesystems\ext2 should go to rosapps.
\drivers\filesystems\minix should go to rosapps.
\drivers\filesystems\template should go to rosapps.
\drivers\multimedia\avtest should go to rosapps.
\drivers\network\tditest should go to rosapps.
\regtests should go to rosapps.

As well, there has been talk that \tools should become part of RosBE as
-O3, heavily optimized binaries on Windows.
They should stay in the default reactos trunk download, but building
them shouldn't be done on Windows unless the binaries can't be found or
the option has been forced. This will make bug reporting and testing
safer since we'll know the tools are the same ones the developers are
using (at least on Windows, where we can manage this better). I am very
much pushing for this change to happen, as it will make our life easier
for a variety of reasons:

- MSVC or GCC 4.2 -O3 tools decrease build times. A highly optimized
rbuild binary does dependency checking almost twice as fast as a regular
-Os binary.
- Decrease build times since the tools don't have to be rebuilt/cleaned
each time.
- Decrease storage space for developers that want to locally delete the
entire tree.
- Reduce the number of potential problems that outside testers might
have to due to improper building of their tools. The tools Microsoft
releases in the DDK are the same ones they use internally, so any bugs
appear on both versions, and it makes diagnosing a lot easier.

Unfortunately binaries can't be provided for Linux, but since /tools
would stay in the reactos directory, Linux builders would be completely
unaffected (except they wouldn't have the added advantages).

As far as I know, Aleksey, Christoph and Johannes are willing to back
this up and do the necessary changes for the /tools; I'll handle fixing
the .xml files and doing the tree moves.

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

[art yerkes]

On Tue, 06 Feb 2007 21:07:26 -0500
Alex Ionescu <ionucu(a)videotron.ca> wrote:

>   Hi all,
>  
>  After talking to some developers about the recent state of the ReactOS
>  tree, compiler times and disk space, I've analyzed our tree and found
>  the following preliminary round of changes that should be made to stay
>  in line with our policy that ReactOS provides what Windows does, at the
>  core level. Any extra functionality or applications not provided by
>  Windows have always been supposed to go into rosapps, as well as test
>  applications. For testing/regression testing, I actually recommend the
>  creation of a ros-tests repository, which will contain the tests in
>  rosapps plus the ones I've mentionned below.
>  
>  This isn't just about disk space or compiling speed, but also to keep
>  our tree clean and conformant.
>  
>  Here's the list:
>   
Overall I agree with most of these, but I would rethink moving drivers to
rosapps.  Maybe there should be a place for non-core drivers?  Sounds like
a good idea for the most part.
-- 
The way out is via the door. Why is it that no one will use this method? - Confucius

[Felipe Villarroel]

+1
just my $0.02

Best regards,
Logan_V8

On 2/6/07, art yerkes <ayerkes(a)speakeasy.net> wrote:
>   On Tue, 06 Feb 2007 21:07:26 -0500
>  Alex Ionescu <ionucu(a)videotron.ca> wrote:
>
> >   Hi all,
> >
> >  After talking to some developers about the recent state of the ReactOS
> >  tree, compiler times and disk space, I've analyzed our tree and found
> >  the following preliminary round of changes that should be made to stay
> >  in line with our policy that ReactOS provides what Windows does, at the
> >  core level. Any extra functionality or applications not provided by
> >  Windows have always been supposed to go into rosapps, as well as test
> >  applications. For testing/regression testing, I actually recommend the
> >  creation of a ros-tests repository, which will contain the tests in
> >  rosapps plus the ones I've mentionned below.
> >
> >  This isn't just about disk space or compiling speed, but also to keep
> >  our tree clean and conformant.
> >
> >  Here's the list:
> >  
>  Overall I agree with most of these, but I would rethink moving drivers to
>  rosapps.  Maybe there should be a place for non-core drivers?  Sounds like
>  a good idea for the most part.
>  --
>  The way out is via the door. Why is it that no one will use this method? - Confucius
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Timo Kreuzer]

I would agree on most of that.

I would vote for keeping downloader in the tree, because it's small and 
gives a good view on what should work on ROS for people testing the 
builds. And it's easier than mounting/editing the image and copying the 
files.
imagesoft could stay in the tree, as we don't have a paint clone or a 
picture viewer.

[Aleksey Bragin]

The whole idea of the tree reorganization is to actually have:
1) /reactos: The bare minimum system, which is able to boot (into  
explorer). No added-values are in this tree (system can work without  
downloader, paint brush and something else).
2) /rosapps: Not a thrash-can where unused stuff goes (which it looks  
like now), but properly setup tree, which most people will compile  
together with /reactos, will provide all the nice things we already  
have - downloader, imagesoft, etc, etc. Those utils are great and  
definately needed to make the system actually look like a working and  
kind of usable system.
3) (maybe?) /rostests: IMO, having tests in rosapps is not the best  
thing, because I would want to construct my own WC that way so I can  
develop/try tests without compiling all applications too. So another  
tree is proposed to contain all tests we have developed so far, plus  
winetests, plus all tests from rosapps too.

Again, most people should be at least the first two, if not all  
three. Only core devs in some cases (like kernel dev, device driver  
development, bootloader work), who can't afford to spend 30 minutes  
recompiling the tree (my Core Duo spends 30 minutes to recompile / 
reactos without additional modules now) should use the 1) or 1)+3)  
options.


With the best regards,
Aleksey Bragin.

On Feb 7, 2007, at 6:52 AM, Timo Kreuzer wrote:

>   I would agree on most of that.
>
>  I would vote for keeping downloader in the tree, because it's small  
>  and
>  gives a good view on what should work on ROS for people testing the
>  builds. And it's easier than mounting/editing the image and copying  
>  the
>  files.
>  imagesoft could stay in the tree, as we don't have a paint clone or a
>  picture viewer.

[Alex Ionescu]

Aleksey Bragin wrote:
>   
>  Again, most people should be at least the first two, if not all  
>  three. Only core devs in some cases (like kernel dev, device driver  
>  development, bootloader work), who can't afford to spend 30 minutes  
>  recompiling the tree (my Core Duo spends 30 minutes to recompile / 
>  reactos without additional modules now) should use the 1) or 1)+3)  
>  options.
>   
Speaking of which... *puts on his angry voice*...

CAN SOMEONE P-L-E-A-S-E GET AROUND TO IMPLEMENTING "MAKE <DIRNAME>" IN
RBUILD?

I've asked this for two months now.

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