Long Awaited Update
Ok, it’s been a few days shy of 2 months since my last post, partly to do with me starting back at University and the other part to do with the current state of ReactOS.
Since my last post quite a lot has happened with ReactOS. Firstly a developer that has now left the project posted a message to the mailing list and forum stating that he found functions in the source tree that were _very_ close to the Windows 2000 & XP functions if you were to compare them to the disassembled code (This isn’t about the leaked source code!). This in turn caused the project to halt for quite a few weeks while the developers talked about what to do behind closed doors (This was not done to hide facts, just to work out what should be done on the matter). After a few meetings the developers decided to change ReactOS' policy on reverse engineering. All reverse engineering now _must_ be done cleanly using a two step process, one person must document the disassembled code while another person uses these documents to implement the function(s). Since it was unknown just how much code in ReactOS was created from dirty reverse engineering, the whole source tree is under going an audit process. Under the audit process each bit of code will be checked too see if it complies with the new policy, if it doesn’t it will be rewritten as soon as possible.
At first a new svn repository was setup for the clean tree. When any segment of the old tree was cleared as being clean it would be copied across. While this works well, it could take months or even years to get ReactOS back up to where it was before all this happened. Since this idea didn’t appeal to everyone, mainly because peoples interest were fading, It was decided by vote that rather than taking the previous approach they would bring the old svn repository back online but lock each segment of the source tree. Once a segment of the source had been cleared it would be unlocked and editable by any developer. This way while allowing the tree to compile properly and into a usable state it also gave developers more incentive to audit and unlock the sections they want to work on.
And that’s pretty much where we are at right now. I’ve added a few links at the bottom if you want to get more details on the situation (Its 1:30am, so this whole article probably makes no sense).
Since my last post quite a lot has happened with ReactOS. Firstly a developer that has now left the project posted a message to the mailing list and forum stating that he found functions in the source tree that were _very_ close to the Windows 2000 & XP functions if you were to compare them to the disassembled code (This isn’t about the leaked source code!). This in turn caused the project to halt for quite a few weeks while the developers talked about what to do behind closed doors (This was not done to hide facts, just to work out what should be done on the matter). After a few meetings the developers decided to change ReactOS' policy on reverse engineering. All reverse engineering now _must_ be done cleanly using a two step process, one person must document the disassembled code while another person uses these documents to implement the function(s). Since it was unknown just how much code in ReactOS was created from dirty reverse engineering, the whole source tree is under going an audit process. Under the audit process each bit of code will be checked too see if it complies with the new policy, if it doesn’t it will be rewritten as soon as possible.
At first a new svn repository was setup for the clean tree. When any segment of the old tree was cleared as being clean it would be copied across. While this works well, it could take months or even years to get ReactOS back up to where it was before all this happened. Since this idea didn’t appeal to everyone, mainly because peoples interest were fading, It was decided by vote that rather than taking the previous approach they would bring the old svn repository back online but lock each segment of the source tree. Once a segment of the source had been cleared it would be unlocked and editable by any developer. This way while allowing the tree to compile properly and into a usable state it also gave developers more incentive to audit and unlock the sections they want to work on.
And that’s pretty much where we are at right now. I’ve added a few links at the bottom if you want to get more details on the situation (Its 1:30am, so this whole article probably makes no sense).
posted by AS at
12:43 AM
|
0 comments
