This may be a good time to restructure the tree? http://www.reactos.org/wiki/Techwiki:File_Layout http://www.reactos.org/wiki/Techwiki:File_Layout This will make ros much more modular and allow things like minwin to be built.
Ged.
On 24 July 2010 19:52, akhaldi@svn.reactos.org wrote:
Author: akhaldi Date: Sat Jul 24 18:52:44 2010 New Revision: 48236
URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev Log: Create a branch for cmake bringup.
Added: branches/cmake-bringup/ (props changed) - copied from r48235, trunk/reactos/
Propchange: branches/cmake-bringup/
--- bugtraq:logregex (added) +++ bugtraq:logregex Sat Jul 24 18:52:44 2010 @@ -1,0 +1,2 @@ +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? +(\d+)
Propchange: branches/cmake-bringup/
bugtraq:message = See issue #%BUGID% for more details.
Propchange: branches/cmake-bringup/
bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID%
Propchange: branches/cmake-bringup/
--- svn:ignore (added) +++ svn:ignore Sat Jul 24 18:52:44 2010 @@ -1,0 +1,14 @@ +*.iso +makefile.auto +makefile-*.auto +config-*.rbuild +obj-* +output-* +reactos +reactos.* +RosBE-Logs +*.sln +*.ncb +*.suo +versionreport.xml +config.rbuild
Propchange: branches/cmake-bringup/
--- svn:mergeinfo (added) +++ svn:mergeinfo Sat Jul 24 18:52:44 2010 @@ -1,0 +1,4 @@ +/branches/header-work:45691-47721 +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064 +/branches/ros-amd64-bringup:36852
+/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882
Propchange: branches/cmake-bringup/
tsvn:logminsize = 10
Anything that will bring more efficiency into trunk as well as remove unused/dead code is worthy of time. Not to mention that trunk gets bigger with almost every day whereas both official and my buildbot machines are not getting faster.
My motion would be cleaning up http://svn.reactos.org/svn/reactos/trunk/ so it contains only code buildable by ROSBE. Right now it is trunk,tests and apps but would get bigger if we modularize trunk and move code around.
By accomplishing that we can make buildbot setup more precize, by setting svn scheduler to this directory, being sure that only buildable code will trigger the build. At the moment we have a tough choice between limiting ourselves only to ros main tree in http://svn.reactos.org/svn/reactos/trunk/reactos or allow changes to documentation, irc, rosdocs, tools and wallpaper directories trigger the build as well. It ends up in heavy hacking if you want trunk+rostests only...
2010/7/25 Ged Murphy gedmurphy@gmail.com
This may be a good time to restructure the tree? http://www.reactos.org/wiki/Techwiki:File_Layout
This will make ros much more modular and allow things like minwin to be built.
Ged.
On 24 July 2010 19:52, akhaldi@svn.reactos.org wrote:
Author: akhaldi Date: Sat Jul 24 18:52:44 2010 New Revision: 48236
URL: http://svn.reactos.org/svn/reactos?rev=48236&view=rev Log: Create a branch for cmake bringup.
Added: branches/cmake-bringup/ (props changed) - copied from r48235, trunk/reactos/
Propchange: branches/cmake-bringup/
--- bugtraq:logregex (added) +++ bugtraq:logregex Sat Jul 24 18:52:44 2010 @@ -1,0 +1,2 @@ +([Ii]ssue|[Bb]ug)s? #?(\d+)(,? ?#?(\d+))*(,? ?(and |or )?#?(\d+))? +(\d+)
Propchange: branches/cmake-bringup/
bugtraq:message = See issue #%BUGID% for more details.
Propchange: branches/cmake-bringup/
bugtraq:url = http://www.reactos.org/bugzilla/show_bug.cgi?id=%BUGID%
Propchange: branches/cmake-bringup/
--- svn:ignore (added) +++ svn:ignore Sat Jul 24 18:52:44 2010 @@ -1,0 +1,14 @@ +*.iso +makefile.auto +makefile-*.auto +config-*.rbuild +obj-* +output-* +reactos +reactos.* +RosBE-Logs +*.sln +*.ncb +*.suo +versionreport.xml +config.rbuild
Propchange: branches/cmake-bringup/
--- svn:mergeinfo (added) +++ svn:mergeinfo Sat Jul 24 18:52:44 2010 @@ -1,0 +1,4 @@ +/branches/header-work:45691-47721 +/branches/reactos-yarotows:46372,46848,46966,47800,48026,48064 +/branches/ros-amd64-bringup:36852
+/branches/ros-amd64-bringup/reactos:34711-34712,34741,34743,34770,34780-34782,34803,34812,34839,34842,34864,34870,34874,34877,34908-34909,34917,34965,35323-35324,35347-35348,35361,35436,35509,35515,35588,35655,35683,35739,35746,35762,35771,35777,35781,35789,35805,35823,35827,35902,35904-35906,35942,35947-35949,35952-35953,35966,36011-36013,36172,36360,36380,36388-36389,36393,36397,36445,36475,36502-36503,36505,36570,36614,36852,36898-36899,36930,36936,36949,36951,36958,36961,36964,36969,36972,36987-36988,36990,36992,37019,37322-37323,37333-37334,37434,37472,37475,37536,37820-37821,37868-37869,37873,37990-37991,38013-38014,38092,38100,38148-38151,38264-38265,38268,38355,39151,39333,39335,39345,39639,40120,40122-40123,40125,40127-40128,40155,40247,40324,40608,40753,40926-40928,40986-40987,40989,40991,40993,40995-40996,41000-41001,41027-41030,41044-41045,41047-41050,41052,41070,41082-41086,41097-41098,41101,41449,41479-41480,41484-41485,41499-41500,41502,41531,41536,41540,41546-41547,41549,43080,43426,43451,43454,43506,43566,43574,43598,43600-43602,43604-43605,43677,43682,43757,43775,43836,43838-43840,43852,43857-43858,43860,43905-43907,43952,43954,43965,43969,43979,43981,43992,44002,44036-44037,44039-44040,44044-44045,44053,44065,44095,44123,44143-44144,44205,44238,44257,44259,44294,44338-44339,44385,44389,44391,44426,44460,44467-44468,44470-44471,44499,44501,44503-44504,44506,44510-44512,44521,44523-44526,44530,44540,44601,44634,44639,44772,44818,45124,45126-45127,45430,46394,46404,46478,46511,46523-46524,46526,46534-46535,46537-46539,46589,46805,46868,47472,47846-47847,47878,47882
Propchange: branches/cmake-bringup/
tsvn:logminsize = 10
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it.
wasn't there already a branch for that task?
Zachary Gorden wrote:
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Yes, there is no sense in doing two mainly unrelated very big tasks simulteneously. Also my own opinion still hasn't changed - existing layout is quite logical (there are exceptions, but they are everywhere), and any modularization could be achieved already with existing tools like sysgen.
Let cmake branch be actual cmake experiment, not an awesome attempt to fix whole ReactOS at once
WBR, Aleksey Bragin.
From: Zachary Gorden Sent: Sunday, July 25, 2010 9:45 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it.
--------------------------------------------------------------------------------
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
The logical layout is exactly what is wrong with the tree. The tree is currently laid out in a manner which you would expect someone who doesn't understand NT architecture. Things are laid out by type instead of by architecture. It makes building individual areas of the operating system very difficult.
On 25 July 2010 19:03, Aleksey Bragin aleksey@reactos.org wrote:
Yes, there is no sense in doing two mainly unrelated very big tasks simulteneously. Also my own opinion still hasn't changed - existing layout is quite logical (there are exceptions, but they are everywhere), and any modularization could be achieved already with existing tools like sysgen.
Let cmake branch be actual cmake experiment, not an awesome attempt to fix whole ReactOS at once [image: Улыбка смайлик]
WBR, Aleksey Bragin.
*From:* Zachary Gorden drakekaizer666@gmail.com *Sent:* Sunday, July 25, 2010 9:45 PM *To:* ReactOS Development List ros-dev@reactos.org *Subject:* Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Do you have any specific proposals, Ged?
Ged's and Timo's ideas are expressed on that wiki page he linked earlier: http://www.reactos.org/wiki/Techwiki:File_Layout
The problem is that change tries to fix rbuild's problems by reshuffling various modules in the tree structure, when the proper solution is to fix the build system itself. A decent build system supports modularization concept in such a way that doesn't require moving actual files around every time we add a new module or group of modules.
WBR, Aleksey Bragin.
From: Zachary Gorden Sent: Monday, July 26, 2010 5:16 AM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmakebringup.
Do you have any specific proposals, Ged?
--------------------------------------------------------------------------------
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Is there some sort of restriction in rbuild regarding the locations of files in a module? Are source code files restricted to a directory?
On 26 July 2010 09:11, Aleksey Bragin aleksey@reactos.org wrote:
Ged's and Timo's ideas are expressed on that wiki page he linked earlier: http://www.reactos.org/wiki/Techwiki:File_Layout
The problem is that change tries to fix rbuild's problems by reshuffling various modules in the tree structure, when the proper solution is to fix the build system itself. A decent build system supports modularization concept in such a way that doesn't require moving actual files around every time we add a new module or group of modules.
WBR, Aleksey Bragin. *From:* Zachary Gorden drakekaizer666@gmail.com *Sent:* Monday, July 26, 2010 5:16 AM *To:* ReactOS Development List ros-dev@reactos.org *Subject:* Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmakebringup.
Do you have any specific proposals, Ged?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Aleksey Bragin schrieb:
Ged's and Timo's ideas are expressed on that wiki page he linked earlier: http://www.reactos.org/wiki/Techwiki:File_Layout http://www.reactos.org/wiki/Techwiki:File_Layout
The problem is that change tries to fix rbuild's problems by reshuffling various modules in the tree structure, when the proper solution is to fix the build system itself. A decent build system supports modularization concept in such a way that doesn't require moving actual files around every time we add a new module or group of modules.
No, you seem to misunderstand the points of the restructure.
First: Rbuild sucks and noone is fixing it. In fact I seem to be the only one working on rbuild at all from time to time and I hate rbuild, I hate makefile stuff. We have sysgen, but noone is working on that either. Now there is an attempt to use CMake, which sucks as well and which will not solve the problems we have, even if ever anyone will be able to build our whole tree with it, which I still doubt. Example: someone adds a new file to drivers/wdm/multimedia/audio/blabla/blabla.rbuild. As a result rbuild rebuilds the makefile and with a chance of 30% starts rebuilding headers, recompiling rbuild, again rebuilding the makefile, compiling the whole damn tree.
It's also not the responsibility of the build system to handle the development process or compensate for a broken file layout. The build system won't help our buildbot when we always do a clean rebuild of the whole branch. The build system won't help us with managing branches, it won't help with updating individual components. Example: I want to commit a small fix in win32k, which goes together with a line in user32. To be able to commit both, I need to start my commit from the reactos root folder and wait 3 minutes before TSVN has finished scanning my WC. Then TSVN tells me I have to update my WC, because someone else comitted to win32k. I can't just update win32k, because it relies on a change in gdi32 as well. So I need to update that as well. So I either end up cherry picking individual modules that I update, which ends up in version fragmentation or I update the whole WC and then recompile everything, because someone else has added a file to blabla.rbuild or fixed a typo in some header.
I remember once someone told me not to commit so often, because buildbot couldn't handle building all those revisions... And they were to a branch. Well that problem is solved, but comitting 10 times in a row to paint will still make buildbot compile crt, rtl, ntoskrnl and everything 10 times in a row, although it's completely unaffected. How do we solve that with rbuild if we always do clean rebuilds. I wonder how long it takes to build the whole windows sources. I don't think at MS they will recompile the whole code base everytime someone makes a change to paint. Doing so is ridiculous. That's why these things need to be seperated. Just "seperating" it with a build system, while the actual files are still being spread all over the place just doesn't work.
Regarding the current layout is logical: We could sort the modules alphabetically, that would be as "logical". But it's not reasonable.
Regards, Timo
-------------------------------------------------- From: "Timo Kreuzer" timo.kreuzer@web.de Sent: Tuesday, July 27, 2010 12:11 AM To: "ReactOS Development List" ros-dev@reactos.org Subject: [ros-dev] Tree restructure (was: Re: [ros-diffs] [akhaldi] 48236: Create a branch forcmakebringup.)
Aleksey Bragin schrieb:
The problem is that change tries to fix rbuild's problems by reshuffling various modules in the tree structure, when the proper solution is to fix the build system itself.
No, you seem to misunderstand the points of the restructure.
Actually I do, that's what I mean:
First: Rbuild sucks and noone is fixing it.
Yes.
It's also not the responsibility of the build system to handle the development process or compensate for a broken file layout.
I'm not really discussing pros or cons of the proposed layout (which I do want to discuss - but later), what I really dislike is a statement about "build system sucks, noone is fixing it, so let's change layout instead of fixing it".
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...
WBR, Aleksey Bragin.
On 26 July 2010 21:29, Aleksey Bragin aleksey@reactos.org 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.
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 Murphy Sent: Tuesday, July 27, 2010 1:23 AM To: ReactOS 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 aleksey@reactos.org 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Aleksey Bragin wrote:
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,/
This is a valid point. One of the few to take care of.
make modules harder to find,
It will actually make modules much easier to find. When I look for a module I usually know what kind of module it is. When I look for gdi32, I know it's a core win32 thing and I don't have to look through hundreds of wine dlls, just to find gdi32. If I don't know what kind of module that is, I should either stay away from it, or simply use doxygen, that will tell me where it is. But this should be really the exception.
whatever else, BESIDES hacking around a broken build system which can't have proper grouping?
Did I write in chineese letters on greek background? How can the build system care for shorter build times if we always do a clean rebuild of *everything*? It can't. How can a different file layout do that? Easy: the buildbot can decide what part of reactos was commited to and only clean and rebuild THAT part. If I commit some audio file, just rebuild the audio part. The rest of the tree is unaffected. We also don't recompile gcc when someone commited to the kernel. The only dependency that all stuff shares is the "SDK", containing the core headers and core libs like crt. This way we could divide our buildbot's build time probably by 5 to 10. Now please tell me how rbuild or cmake or sysgen can do that? Another thing is dependencies. Currently everyone just adds dependencies wherever he likes. There's so much interdependency you can't just not build something like dlls. For the amd64 port, I added a bunch of hacks to only compile kernel mode stuff to save a lot of compilation time, but that took me quite some time to get it working and it's pretty hacky. The new file layout would allow to simply "comment out" one directory from the root folder and still everything would build.
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.
The only thing on the other side of the argumentation that I heard so far is, that it doesn't matter how bad our file layout is, we can work around it with a complex build system. But that's not true.
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.
Now this is a story all about how somebody's life got flip turned upside-down. I'd like to take a minute, just sit right there. I'll tell you about some guy called Adam Bow
Adam lives in a nice 5 room appartment and he has a very strict tidyness: - In the 1st room he keeps everything that is made from metal - In the 2nd room he keeps everything that imade from plastic - In the 3rd room he keeps everything that is made from glass - In the 4th room he keeps everything organic - In the 5th room he keeps all electronics
Now one day when he starts to make his meal, he goes into the 1st room to get a pot, into the 2nd room to get some bowl, in the 3rd room to get a bottle of vinegar, in the 4th room to get potatoes, in the 5th room to put the pot on the oven, ... he runs through all his rooms over and over again. That annoys him so much that he thinks about a solution. After 3 days constantly thinking, he has the solution: he installs a railway going through all of his 5 rooms, so he can just sit on a wagon and drive through his house.
Just a reminder to all involved in this discussion, the work with cmake has one goal, which is to remove our dependency on rbuild and the maintenance load that using it entails. rbuild has a lot of issues by itself, irrespective of the problems it causes in combination with the directory hierarchy, but trying to go to cmake isn't designed to solve those problems, just the ones rbuild itself causes. It may ultimately make solving the combined issues easier, but that's a secondary, albeit important, consideration. That restructuring of the directories will likely be necessary has very little to do with the cmake effort itself. So let's not conflate the two issues.
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@reactos.org [mailto:ros-dev-bounces@reactos.org] 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:gedmurphy@gmail.com Murphy
Sent: Tuesday, July 27, 2010 1:23 AM
To: ReactOS mailto:ros-dev@reactos.org 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 aleksey@reactos.org 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
From: Ged Murphy Sent: Tuesday, July 27, 2010 12:06 PM To: 'ReactOS Development List' Subject: Re: [ros-dev] Tree restructure (was: Re:[ros-diffs] [akhaldi]48236: Create a branch forcmakebringup.)
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?
I think it's best to do kind of a summary of pros vs. cons. I remember we spent quite some time discussing it with him, but (Timo - correct me if I'm wrong) his argumentation was that it's "more logical", which is quite subjective.
So you want more reasons?
Agreed about alphabetical, but that's exaggeration.
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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
Imagine if Linux wasn't modularized and changes made to X or Gnome forced rebuilds of the kernel. It would be carnage.
ReactOS is modularized a lot more really. Linux is a ball made of interdependent threads. If they used RBuild, they would get libusb recompiled evertime a comment in the KMail app source code was changed.
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.
Agreed about branching.
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.
What I really want is that if I have four modules: a, b, c and d, which could be located at any relative path inside the build tree. So what I want is being able to specify a few targets, e.g. all being a+b+c+d, kernel being a+b, minwin being a+b+c, and build specified target!
So if looking into the future of my example I want minwin to include component d, I don't have to move source code files of the d component, but just mark it as belonging to the minwin group. With your example we would have to reshuffle files everytime we think module's contents should be changed.
Also with your example of a new tree layout as an aid for better building, we can't have two targets sharing same modules unless they are physically located under one subdirectory. A substantial constraint really. And overall, it sounds like hacking our tree layout to suit sucky build system, not vice versa.
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] 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 Murphy
Sent: Tuesday, July 27, 2010 1:23 AM
To: ReactOS 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 aleksey@reactos.org 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
--------------------------------------------------------------------------------
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
That made for hard reading. I've split my original points up so anyone following this can understand it.
I'll reply when I have some time :)
From: Ged Murphy Sent: Tuesday, July 27, 2010 12:06 PM To: 'ReactOS Development List' Subject: Re: [ros-dev] Tree restructure (was: Re:[ros-diffs] [akhaldi]48236: Create a branch forcmakebringup.)
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?
I think it's best to do kind ofa summary of pros vs. cons. I remember we spent quite some time discussing it with him, but (Timo - correct me if I'm wrong) his argumentation was that it's "more logical", which is quite subjective.
So you want more reasons?
Agreed about alphabetical, but that's exaggeration.
Id 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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
Imagine if Linux wasnt modularized and changes made to X or Gnome forced rebuilds of the kernel. It would be carnage.
ReactOS is modularized a lot more really. Linux is a ball made of interdependent threads. If they used RBuild, they would get libusb recompiled evertime a comment in the KMail app source code was changed.
The proposed layout also lends itself well to the branching system weve been wanting to work towards. Branches could be more easily assigned to specific areas and wed be able to give out commit access more easily.
Agreed about branching.
As the tree grows I really dont see how the current layout will remain feasible. Something will have to change and I dont think hacking the build system around a broken tree structure is the answer.
What I really want is that if I have four modules: a, b, c and d, which could belocated at any relative path inside the build tree. So what I want is being able to specify a few targets, e.g. all being a+b+c+d, kernel being a+b, minwin being a+b+c, and build specified target! So if looking into the future of my example I want minwin to include component d, I don't have to move source code files of the d component, but just mark it as belonging to the minwin group. With your example we would have to reshuffle files everytime we think module's contents should be changed. Also with your example of a new tree layout as an aid for better building, we can't have two targets sharing same modules unless they are physically located under one subdirectory. A substantial constraint really. And overall, it sounds like hacking our tree layout to suit sucky build system, not vice versa.
Ged.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] 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 Murphy Sent: Tuesday, July 27, 2010 1:23 AM To: ReactOS 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 aleksey@reactos.org 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@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev ________________________________________ _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
Isn't it possible to do hard links with svn, git or whatever?
So as in your example, mmsys.cpl would be located in the audio sub tree, and hardlinked to the UI/cpl directory.
All modern filesystems support hard links, that wouldn't suprise me if modern version control systems would do the same.
What do you think?
And here is what I said. http://svnbook.red-bean.com/en/1.0/ch07s03.html
Jérôme Gardou wrote:
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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
Isn't it possible to do hard links with svn, git or whatever?
So as in your example, mmsys.cpl would be located in the audio sub tree, and hardlinked to the UI/cpl directory.
All modern filesystems support hard links, that wouldn't suprise me if modern version control systems would do the same.
What do you think?
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Sorry, for some reason Windows Mail screwed up when I was answering between the lines in your email. ( That's why I like MacOS X's mail client :) )
Thanks for reposting with quotation marks.
WBR, Aleksey..
-------------------------------------------------- From: "Ged Murphy" gedmurphy@gmail.com Sent: Wednesday, July 28, 2010 6:45 PM To: "'ReactOS Development List'" ros-dev@reactos.org Subject: Re: [ros-dev] Tree restructure (was:Re:[ros-diffs] [akhaldi]48236:Createa branch forcmakebringup.)
That made for hard reading. I've split my original points up so anyone following this can understand it.
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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
That seems perfectly reasonable to me. Control panel applets shouldn't be grouped together as they aren't related. They're just dlls. In fact, they aren't even stored together inside Windows, they're COM registered components which can live anywhere on disk. We group them together as if we're end users and are too dumb to know where they should be stored. We aren't dumb end users, we're devs who are supposed to know how things are architecture.
Imagine if Linux wasn't modularized and changes made to X or Gnome
forced
rebuilds of the kernel. It would be carnage.
ReactOS is modularized a lot more really. Linux is a ball made of interdependent threads. If they used RBuild, they would get libusb recompiled evertime a comment in the KMail app source code was changed.
Reactos is modularized in its architecture (as per NT), but it it's not modularized in its tree. If it was then csrss, win32k, gdi32 and user32 would be stored together, instead they're separated and stored with 3rd party Wine code.
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.
What I really want is that if I have four modules: a, b, c and d, which could be located at any relative path inside the build tree. So what I want is being able to specify a few targets, e.g. all being a+b+c+d, kernel being a+b, minwin being a+b+c, and build specified target! So if looking into the future of my example I want minwin to include component d, I don't have to move source code files of the d component, but just mark it as belonging to the minwin group. With your example we would have to reshuffle files everytime we think module's contents should be changed.
That's a nice build feature but you'd only be implementing it due to the messy nature of the tree. You'd still have to check out the whole tree if you're only interested in building and working on minwin. Why a kernel dev would ever be interested in checking out and building notepad or shdocvw.dll is beyond me.
Also with your example of a new tree layout as an aid for better building, we can't have two targets sharing same modules unless they are physically located under one subdirectory. A substantial constraint really. And overall, it sounds like hacking our tree layout to suit sucky build system, not vice versa.
So by this argument, how would you have two win32 subsystems? (win32 and arwinss) \dll\win32 would have two user32 and two gdi32 dlls. Which one is the right one for the subsystem? Do we name one gdi32_arwinss.dll? In the suggested layout you would have \win32core\subsystems dir and have .\win32 and .\arwinss subdir. Each sub dir could then contain all the components to go with that modules, including tests frameworks.
Forget about reactos for a sec, think about how it works in industry . If you were writing a large solution made up of many components, would you structure your solution so that all the drivers, dlls, exes and tests lived in directories by type? No, what you would do it to group things together. Each exe would be stored with its dll, driver and test modules. It makes it easier to develop, build and test. It makes it easier for people to work on certain modules. It makes it easier to swap or replace things. It's how most large software projects structure their trees ... except reactos.
Ged.
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
Yes, but imagine someone who's going to work on Control Panel Applets, e.g. a UI person (if we had one), who would need to work with all CPLs in the system. He would need to find them throughout whole tree, ask in ros-dev ML if he missed any and abandon his idea soon after starting.
I can't see how hard that would be to do. Build ROS, do a search for .cpl files in output-i386, make a note of their paths then find their equivalent source files.
Andrew Faulds http://ajf.me/
I might be a bit of a n00b but at this stage, I also support this restructuring of the tree. I also see a potential for optimizing builds to allow for building a set of components, as opposed to having to work out what components go with what and build them all individually.
Might also help as there are loads of branches in the repository, many that haven't been updated in years, that can be easily reduced in size and/or merged as a result of the scheme.
That's just my thoughts on it, but I'm not really had more than about 3-4+ months experience with the ReactOS codebase.
On Mon, 26 Jul 2010 04:46:07 +1000, Ged Murphy gedmurphy@gmail.com wrote:
The logical layout is exactly what is wrong with the tree. The tree is currently laid out in a manner which you would expect someone who
doesn't understand NT architecture. Things are laid out by type instead
of by architecture. It makes building individual areas of the operating system very difficult.
On 25 July 2010 19:03, Aleksey Bragin aleksey@reactos.org wrote:
Yes, there is no sense in doing two mainly unrelated very big tasks simulteneously. Also my own opinion still hasn't changed - existing
layout is quite logical (there are exceptions, but they are
everywhere), and any modularization could be achieved already with existing >>tools like sysgen. Let cmake branch be actual cmake experiment, not an awesome attempt to fix whole ReactOS at onceWBR, Aleksey Bragin.
From: Zachary GordenSent: Sunday, July 25, 2010 9:45 PM To: ReactOS Development ListSubject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and
if/once that is merged into trunk, then we look into changing the
structure. Best not to complicate one task by adding more to it.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I think that the tree reshuffle should be done separately from the cmake branch. I also agree with Ged that it isn't very logical, so from this point of view I support the tree restructure. On the other hand ReactOS is in a really bad shape form a user point of view and all the resources should focus on fix the most important bugs and regressions listed in http://www.reactos.org/wiki/Buglist. The rest of the things is of a minor importance to me. We can't do everything at the same time, we should focus and things of major importance at the moment. Just my 2 cents.
Gabriel.
To: ros-dev@reactos.org; gedmurphy@gmail.com Date: Fri, 30 Jul 2010 21:05:10 +1000 From: geekdundee@gmail.com Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
I might be a bit of a n00b but at this stage, I also support this restructuring of the tree. I also see a potential for optimizing builds to allow for building a set of components, as opposed to having to work out what components go with what and build them all individually. Might also help as there are loads of branches in the repository, many that haven't been updated in years, that can be easily reduced in size and/or merged as a result of the scheme. That's just my thoughts on it, but I'm not really had more than about 3-4+ months experience with the ReactOS codebase. On Mon, 26 Jul 2010 04:46:07 +1000, Ged Murphy gedmurphy@gmail.com wrote:
The logical layout is exactly what is wrong with the tree. The tree is currently laid out in a manner which you would expect someone who doesn't understand NT architecture. Things are laid out by type instead of by architecture. It makes building individual areas of the operating system very difficult. On 25 July 2010 19:03, Aleksey Bragin aleksey@reactos.org wrote:
Yes, there is no sense in doing two mainly unrelated very big tasks simulteneously. Also my own opinion still hasn't changed - existing layout is quite logical (there are exceptions, but they are everywhere), and any modularization could be achieved already with existing tools like sysgen.
Let cmake branch be actual cmake experiment, not an awesome attempt to fix whole ReactOS at once
WBR, Aleksey Bragin.
From: Zachary Gorden Sent: Sunday, July 25, 2010 9:45 PM To: ReactOS Development List Subject: Re: [ros-dev] [ros-diffs] [akhaldi] 48236: Create a branch forcmake bringup.
I also support a reshuffling of the directories, but not in the cmake branch. Let that be used JUST for getting cmake up and running and if/once that is merged into trunk, then we look into changing the structure. Best not to complicate one task by adding more to it.
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
-- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. _________________________________________________________________ Avatar per Messenger e sfondo per il PC. Creali gratis! http://www.experience.windows.com/landing2.aspx?culture=it-it
Having a proper build system and a good tree structure is a mandatory step to work efficiently. As long as we have neither of them, it is a priority. That's just my opinion, though...
Gabriel ilardi wrote:
I think that the tree reshuffle should be done separately from the cmake branch. I also agree with Ged that it isn't very logical, so from this point of view I support the tree restructure. On the other hand ReactOS is in a really bad shape form a user point of view and all the resources should focus on fix the most important bugs and regressions listed in http://www.reactos.org/wiki/Buglist. The rest of the things is of a minor importance to me. We can't do everything at the same time, we should focus and things of major importance at the moment. Just my 2 cents.
Gabriel.
Answers inlined.
Having a proper build system and a good tree structure is a mandatory step to work efficiently. As long as we have neither of them, it is a priority. That's just my opinion, though...
In my opinion there are more mandatory things:
1) Avoiding to commit partial code. For partial code or partial-semi-working features you can use branchs. 2) Just tested code commited to trunk. You can make (ab)use of testers or try in your own. We have regressed a lot after the big bug hunting. 3) Freezing trunk until the current code is stable enough. In the same way Windows invented the word "Downgrade" with Vista we have invented the "RegressOS" word. 4) And then, after we have "something" we can improve the "something". 5) And after that we can talk about changing to Git, using CMAKE,and restructuring a Tree, or a Forest.
I am not saying a restructure is needed, or moving to CMAKE is a bad thing. But we have better things to be done.
On the other hand ReactOS is in a really bad shape form a user point of view and all the resources should focus on fix the most important bugs and regressions listed in http://www.reactos.org/wiki/Buglist. The rest of the things is of a minor importance to me. We can't do everything at the same time, we should focus and things of major importance at the moment. Just my 2 cents.
Full agree. +1000000.
Freezing Trunk asap or a serious movement to fix the regressions (reverts allowed).
On 30 July 2010 22:44, victor martinez vicmarcal@hotmail.com wrote:
On the other hand ReactOS is in a really bad shape form a user point of view and all the resources should focus on fix the most important bugs and regressions listed in http://www.reactos.org/wiki/Buglist. The rest of the things is of a minor importance to me. We can't do everything at the same time, we should focus and things of major importance at the moment. Just my 2 cents.
Full agree. +1000000.
Freezing Trunk asap or a serious movement to fix the regressions (reverts allowed).
We need this, else it may be another millennia until 0.3.12... -- Andrew Faulds (AJF) http://ajf.me/
Op 30-7-2010 23:52, Andrew Faulds schreef:
We need this, else it may be another millennia until 0.3.12...
Nothing wrong with celebrating (likely soon upcoming) commit 50.000 by releasing it as 0.3.12 or so ^^.
On 30 July 2010 22:44, victor martinez vicmarcal@hotmail.com wrote:
In my opinion there are more mandatory things:
- Avoiding to commit partial code. For partial code or
partial-semi-working features you can use branchs. 2) Just tested code commited to trunk. You can make (ab)use of testers or try in your own. We have regressed a lot after the big bug hunting. 3) Freezing trunk until the current code is stable enough. In the same way Windows invented the word "Downgrade" with Vista we have invented the "RegressOS" word. 4) And then, after we have "something" we can improve the "something". 5) And after that we can talk about changing to Git, using CMAKE,and restructuring a Tree, or a Forest.
I am not saying a restructure is needed, or moving to CMAKE is a bad thing. But we have better things to be done.
Although valid, I don't think any of your points have anything to do with a tree restructure. Maybe you misunderstand the reasoning behind the proposed architecture and what it can do to help us?
Anyone who is unsure should speak with Timo or maybe lassy in IRC and they can better help to explain it from a development perspective.
Ged.
-
Adam Kachwalla -
Aleksey Bragin -
Andrew Faulds -
Bernd Blaauw -
Gabriel ilardi -
Ged Murphy -
Jérôme Gardou -
Olaf Siejka -
Timo Kreuzer -
victor martinez -
Zachary Gorden