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
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.
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
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.
> 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
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
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
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
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
