Re: [ros-dev] Tree restructure (was: Re: [ros-diffs] [akhaldi]48236: Create a branch forcmakebringup.)

[Ged Murphy]

Timo has given you various scenarios as to where the proposed system is an
improvement on the existing.

Maybe someone can give an reason as to why the current layout is better than
the suggested one?

 

So you want more reasons?

Instead of focusing on the build, which is where most of our arguments have
lay so far, I'll discuss the merits from a tree structure perspective:

 

Firstly, I don't agree with the 'easier to find' statement. This may be true
for someone with no knowledge of NT, but reactos devs are supposed to know
this stuff.

If the 'easier to find' statement was valid, then I think Timo's suggestion
of laying everything out alphabetically would be better still.

 

I'd much prefer to go to the audio directory to work on everything from
portcls.sys up to mmsys.cpl. Things could be committed together instead of
separately forcing 2 separate builds on buildbot

 

You have to look to the future. Let's consider how Microsoft will do things.


Do you think the Windows source code is dumped into one big TFS database
with everything filed under module type?

This would mean Joe on the kernel team would be effected by what Sam in the
audio department is doing. Changes made by Steve on the COM team might force
a rebuild of what Ian is working on in the shell team.

You can't expect everyone to have a separate branch of the entire source
code to avoid this problem. The code is modularized and people are given
access to the areas which they work on.

 

Imagine if Linux wasn't modularized and changes made to X or Gnome forced
rebuilds of the kernel. It would be carnage. 

 

The proposed layout also lends itself well to the branching system we've
been wanting to work towards. Branches could be more easily assigned to
specific areas and we'd be able to give out commit access more easily.

-          Student devs could be given access to the applications directory.

-          We could build up an ntcore directory, make it bootable (aka
minwin) and kernel devs could be given branches to this area without the
noise of a full OS.

-          Graphics guys could be checkout the build tools, an ntcore and a
win32core areas. They could have write access to win32core and work on that
without worrying about what the student devs are doing in the apps dir.

 

 

As the tree grows I really don't see how the current layout will remain
feasible.

Something will have to change and I don't think hacking the build system
around a broken tree structure is the answer.

 

Ged.

 

 

 

From: ros-dev-bounces(a)reactos.org [mailto:[e-mail]] On
Behalf Of Aleksey Bragin
Sent: 26 July 2010 23:10
To: ReactOS Development List
Subject: Re: [ros-dev] Tree restructure (was: Re: [ros-diffs]
[akhaldi]48236: Create a branch forcmakebringup.)

 

Please, this would be my last reply to this thread. Yet another time I'm
getting an answer that reshuffling files in the directory makes build time
shorter. Seriously, am I writing with background and foreground text colors
being set to the same value or what?

 

Is there any real, serious reason to break compatibility with all existing
branches, make modules harder to find, whatever else, BESIDES hacking around
a broken build system which can't have proper grouping? I proposed to
properly solve this with either sysgen, cmake or anything else. With a build
system which does not suck. Not with a build system, where you need to
adjust file paths in order to be able to control build process!

 

I'm glad to participate in a discussion about pros and cons of a proposed
new tree layout, but so far the only thing I keep listening to is that it's
somehow going to make build time shorter. Let's be honest: It won't. If a 1
liner in PSDK causes whole tree to rebuild, it will take the same with the
new layout. It will just be built in a different order, but still all will
be rebuilt, because of (somehow broken, or too strict, or incompatible with
the makefile) dependencies tracking. It won't make build time shorter until
a new build system is in place.

 

WBR,

Aleksey Bragin.

 

 

From: Ged <mailto:[e-mail]>  Murphy 

Sent: Tuesday, July 27, 2010 1:23 AM

To: ReactOS <mailto:[e-mail]>  Development List 

Subject: Re: [ros-dev] Tree restructure (was: Re: [ros-diffs]
[akhaldi]48236: Create a branch forcmakebringup.)

 

 

On 26 July 2010 21:29, Aleksey Bragin &lt;aleksey(a)reactos.org&gt; wrote: 

 

Regarding the current layout is logical: We could sort the modules
alphabetically, that would be as "logical". But it's not reasonable.

Great, we came to an agreement: it is logical :). Reasonability is
discussable...

 

 

I'm yet to hear any arguments as to how the current layout is better than
the suggested one.

 

As the tree grows in size it's going to become more and more difficult to
manage.

Do we really have to wait until we're at a point where it takes 5 hours to
build after making a 1 line change to a PSDK file?

 

As far as I can tell, our current layout, by type, only serves to make
modules easy to find.

In comparison, Timo's alphabetical point is actually as reasonable as the
current layout. 

 

Ged.

  _____  

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev