Ros-dev January 2006

ros-dev@reactos.org

69 participants
136 discussions

Proposal for a new "Documentation Management" group
by Wierd_w 29 Jan '06

29 Jan '06

Just an idea to kick around-- With the recent issues of reverse engineering, and our new-- extra stern-- IP policy, it appears that "cleanroom implementation" (US style) is going to be very strictly adhered to. This raises a few concernes to me, even though I dont develop code. 1) The developers that decide they will become(Stay) reverse-engineers are going to have a great deal on their plate allready. Not only will they have to decompile proprietary binaries, but they will also have to make documentation about the functions within those binaries. Asking them to manage the collective work of both themselves and other reverse engineers is asking too much. 2) Implementors are not allowed to have direct communication with reverse engineers, under US style CleanRoom implementation practices. So, I propose a new group classification, with the purposes of 1) Organizing, catalogueing, and possibly correcting (For spelling, and other grammaticals) the whitepaper documentation produced by the reverse engineers. 2) Offering the functional service of communicating with the reverse engineers any objections, or concerns the implementors might have. (EG, "XXXX XXXX does XXX XXX by YYYYY" is not sufficent to explain what is going on, can I get a better description?", the documentation manager group would contact the reverse engineer in question, and ask them to make an adendum to their documentation to address this issue, and would then contact the implementor after such addendum(s) have been completed, and filed.) This group would thus have responsibilities simmilar to "Editor", "Librarian", and "Secretary", which is why I propose the generic name "Documentation Manager(s)." If there is allready such a position/group, I withdraw the proposal. Otherwise, I dont see how we could really hope to pull this off without dedicated individuals on this task. (PS, having "non-Coders" on this taskforce would probably alleviate any allegations of contamination between reverse engineers and Implemntors, in that it is unlikely that the secretary in question would understand a very technical request to begin with, and thus be unable to pass on any such complicated requests in their duties as secretary. It would also give some really strong enthusiasts something to do-- All you need are clerical and communication skills.) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Samba 4.0TP (Second Post)
by Rick Langschultz 28 Jan '06

28 Jan '06

Has anyone checked out the Samba 4.0 Tech Preview? I think the NTVFS folder includes code that allows another FS to act like NTFS. But take a look and tell me if integration to ReactOS would be a good idea.

1 0

ntdocs diff
by Jerry 28 Jan '06

28 Jan '06

Please ignore my last diff; this is an improved version. This diff sets up a directory (ntdocs) where documention and test cases and be put. I sugest that the tree for this dir should mirror the actual code base for ease of use. Thanks. Index: ntdocs/readme.txt =================================================================== --- ntdocs/readme.txt (revision 0) +++ ntdocs/readme.txt (revision 0) @@ -0,0 +1,6 @@ +This directory contains the documentation for Reactos (test cases and the like). Please do NOT put actual code here. +Just enough to implement it. Only human lanuage and puedo-code is allowed here. If you reversed engeneered, it please keep the policy and DO NOT implement it. + +The tree layout for the docs should mirror that of the actual code tree for ease of use. + +Thanks. \ No newline at end of file

2 1

How to audit.
by Jerry 28 Jan '06

28 Jan '06

I think we need to be more organized in this endeavor. We need to decided who will look at chuck of code, so that the process goes faster. I suggest that we pair up into two person teems whose responsibility is to decide if a certain group of code it dirty or not. These teems will then look at their area of code systematicly, deciding if part or alll of the code they come across is dirty. All the clean code will then be put into the audited trunk, then the stripped stub of the functions that were dirty.

1 0

RE: [ros-diffs] [chorns] 11: Document rbuild
by Ge van Geldorp 28 Jan '06

28 Jan '06

> From: chorns(a)svn.reactos.org > > Document rbuild > Property changes on: trunk/reactos/tools/rbuild > Name: svn:doc It seems your brain is pre-wired to type "svn:..." after "propset" :-) GvG

2 1

what about stuff we share with Wine?
by Jonathan Wilson 28 Jan '06

28 Jan '06

Are we going to have to audit that too? Is there a risk that Wine might contain compromised code somehow?

2 1

Propose standards for the audit
by Steven Edwards 28 Jan '06

28 Jan '06

Hello, Ok here are some proposed ground rules for the audit. Mostly thanks to Art and Alex. We are still open for debate on this 0. Everyone needs commit all documentation you have reverse enginered something so that someone else can reimplement it. Filip has some nice docs at http://www.volny.cz/xnavara/doc_trash/ There is stuff I posted on the Wiki and Bugzilla. Can someone make a api-documentation module in svn and commit all this stuff to there? 1. A function is deemed to have been implemented in a non-clean manner if - "unknown" arguments given values - functions for which there is NO DOCUMENTATION - functions with no test cases available either in ReactOS or somewhere on the internet - functions with undocumented magic numbers - functions with excessive gotos NO DOCUMENTATION means it cannot be found on MSDN, Google, sysinternals, osronline, any book published by Microsoft Press or any other publication. 2. The following does not count - functions of 5 or less lines of code - functions for which every basic unit corresponds to a clause in the official documentation - functions which mimic those implemented in other libraries and that work similarly 3. Even if the function body is not clean, the prototype can remain. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

8 13

rev-doc diff.
by Jerry 28 Jan '06

28 Jan '06

I thought it would be a great idea to put all the reversed engineered documentation in a separate directory in the audited trunk. Here is the diff to set it up (attachment). Thanks. Index: rev_doc/readme.txt =================================================================== --- rev_doc/readme.txt (revision 0) +++ rev_doc/readme.txt (revision 0) @@ -0,0 +1,4 @@ +This directory contains the documentation from reverse engineering. Please do not put actual code here. +Just enough to implement it. If you reversed engeneered it please keep the policy and do NOT implement it. + +Thanks. \ No newline at end of file

2 2

Cleaned up skeleton?
by Jan Schiefer 28 Jan '06

28 Jan '06

Just a very, very vague question: When can the public exspect access to a ( surely very leaky ) cleaned up skeleton of ROS? I mean that we have a running system, without the unchecked ( unclean ) components, so that people can start working again on the clean code. For example: We can boot and explorer pops up. Nothing more. So we can fix bugs in NTOSKRNL, FREELDR and EXPLORER... Greetings, Jan Schiefer

3 3

Build system
by Martin Fuchs 28 Jan '06

28 Jan '06

Hi, as the repository is being set up fresh, I think this would be the best time to correct some problems with the directory layout and file naming schemes. The rbuild input files have been named "*.xml". Yes, these files are XML files. But it's not the best name for them. It would clash with XML files being used by the built applications itself. So I propose to rename all those "*.xml" files of the rbuild system to "*.rbld". What do you think about this idea? Regards, Martin

5 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev January 2006