Hi all.
Would someone be willing to put a flow chart together on moving code from the main branch to the audited branch. I think if something like this is put in place, it would ensure everyone was operating in the same manner.
Pasted from IRC when discussing the audit methodologies:
<GedMurphy> I understand what qualifies for being 'unclean' (which it seems most of ReactOS will be initially), in which case it should be placed into the intermediate repository. However it isn't clearly stated what happens then. If documentation can't be located or test cases aren't written, how is that code further analized? <sedwards> If the code is 'unclean' then someone need to mark themselves down to rewrite it on the audit page <GedMurphy> but what if it's not unclean, but there is no documentation for it? Is it automatically deemed to be unclean in that case? <GedMurphy> e.g. Exception wrote most of the original part of the network stack. I'm positive this was done in a clean manner, but where are the docs? Does he still have them? What happens if there aren't any or they have been lost? <GedMurphy> does rewriting them automatically mean that code is then ok? <GedMurphy> senario 2. No docs can be found, but someone writes some. If that code was ripped from Windows assemblies but we provide docs, that code might get through. However it doesn't get around the fact that it's been 'borrowed' from Windows dissasemblies. <GedMurphy> at what point in the audit is the code checked for similarities to the Windows counterpart, if at all? <GedMurphy> This is what I mean by set methodologies. Something should be laid down, like a flow chart
I would offer to do it, but I think one of our more experienced dev would make a better job. Maybe someone who has done something like this before. I was hoping for one to follow for myself to make sure I don't drop a b*ll*ck :)
Ged.
Ged Murphy wrote:
Hi all.
Would someone be willing to put a flow chart together on moving code from the main branch to the audited branch. I think if something like this is put in place, it would ensure everyone was operating in the same manner.
I hope someone would have a plan! I want to get started ASAP! But everyone are stuck on stupid, IP crap!
On Tue, 31 Jan 2006 22:29:55 +0000 James Tabor jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net wrote:
Ged Murphy wrote:
Hi all.
Would someone be willing to put a flow chart together on moving code from the main branch to the audited branch. I think if something like this is put in place, it would ensure everyone was operating in the same manner.
I hope someone would have a plan! I want to get started ASAP! But everyone are stuck on stupid, IP crap! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Not sure how much sense it makes, but this is my plan:
1) Take the next easiest part to audit 2) Identify components in common with other object files of the same type 3) Document tasks which must be undertaken by these components (if those documents don't already exist) 4) Analyze the code for the component, first grouping functions under categories identified by the building block documents and justifying their code according to the language in the building block documents. This should dentify file names and line numbers and be very specific. 5) Identifying code that was not named in the above and showing it to be either obvious or necessary in context. 6) Code that is neither obvious nor obviously necessary should be shown to be necessary through a test case.
This isn't 100% objective yet, but I think most of it is close.
That's the best I can come up with... Thoughts?
art yerkes wrote:
Not sure how much sense it makes, but this is my plan:
- Take the next easiest part to audit
- Identify components in common with other object files of the same type
- Document tasks which must be undertaken by these components (if those documents don't already exist)
- Analyze the code for the component, first grouping functions under categories identified by the building block documents and justifying their code according to the language in the building block documents. This should dentify file names and line numbers and be very specific.
- Identifying code that was not named in the above and showing it to be either obvious or necessary in context.
- Code that is neither obvious nor obviously necessary should be shown to be necessary through a test case.
Cool!
Wow! Sound like a programming lab assignment! What are we doing prof? Cleaning up after your research? So you can get your masters?
This isn't 100% objective yet, but I think most of it is close.
That's the best I can come up with... Thoughts?
Well since we are using the new directory layout, what is need to do, to fix header includes and build xml info? Template? Where?
What about ntgdibad.h, everything in there is good, right?
Thanks, James
Hi,
On 1/31/06, James Tabor jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net wrote:
What about ntgdibad.h, everything in there is good, right?
I think so. I don't see anything wrong with using the header about fixing the win32k exports now that Alex has documented it via the header.
-- 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