12 Mar
2009
12 Mar
'09
2:16 p.m.
Noone proposed to change tree layout, I like it a lot. And it should
be kept intact.
The question is - do we want to separate non-essential apps into a
standalone module, and separate additional, not present in Windows
apps into yet another module?
Or get rid of almost everything in rosapps, and merge what's left
into trunk?
On Mar 12, 2009, at 4:34 PM, Steven Edwards wrote:
2009/3/12 Aleksey Bragin <aleksey(a)reactos.org>rg>:
So, are there any objections in separating
thirdparty, additional,
sometimes
helpful stuff into addons module, and having all apps which exist in
Windows, but aren't required for booting into rosapps?
Please, let's come to a solution, because having such a trash can
which
rosapps is now is unbearable.
Good riddance but I would go a step further. What are you planning on
leaving in reactos and what are you planning on moving to rosapps?
Without a clear outline I think its risky to say 'sure split it as you
desire'. The current tree layout represents a lot of work and design
Alex did long ago and I am hesitant to see it divested without a wiki
page explaining what is going where.
I mean if your going to strip it down to only the applications
required for booting then I think you should move all non essential
services over as well. My thinking is something more radically
different along the lines of the attached screenshot. But my question
is, what does it gain? Without a change in behavior, your just moving
the problem around.
My thinking is that we are never going to get around the
interdependancy mess with the sdk/ddk/ndk/wine/w32api. However, we can
make it a requirement that we limit commits that affect across
submodules to window. Perhaps changes from each module have to be
merged one day a week or something. This way developer joe does not
commit Wine code and SDK changes on tuesday that force developer fred
to update and rebuild the entire ReactOS tree to merge. Likewise
perhaps rbuild changes can only be merged on Sundays so we've got the
whole week to deal with them.
Hear me out on this. Something like
1. Changes to base,user, services, whatever that does not affect
another module can go in the tree 24x7
2. Wine dlls updates that affect sdk/ddk/ndk follow sdk rules, Simple
Wine updates not requiring IDL changes can go in any time as in rule
1.
3. WineSDK, third party libs, sdk/ddk/ndk,rbuild and rosbe changes get
merged on the weekends
So my thoughts are a little rough around the edges but you get the
idea. The hope is we make the tree pretty granular and we know ahead
of time when major breakages are going to happen. I suspect others
have ideas too. I think before we go moving anything we need to wikify
the plan as Alex did last time we had a major tree restructuring
because it served us very well.
There is nothing wrong with having a window for merges, with modern
revision control, everyone is free to have a branch that is their own
private playground and it just makes sense for the stability of
everyone to limit the times at which we merge. If we are not going to
do this, then changing the layout seems pretty pointless to me.
Thanks
P.S. I just remembered, I left a test/kernel test/winetest module off
the list. It is imperative that we make it to where any commits+merges
that result in a test failure be rejected. non-trunk commits/merges
could be free to fail all day long.
--
Steven Edwards