aleksey at reactos.org
Thu Mar 12 15:16:50 CET 2009
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
On Mar 12, 2009, at 4:34 PM, Steven Edwards wrote:
> 2009/3/12 Aleksey Bragin <aleksey at reactos.org>:
>> So, are there any objections in separating thirdparty, additional,
>> 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
>> 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
> 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.
> 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
More information about the Ros-dev