[OWASP-LEADERS] New Member and 1st step to getting more organized

Ingo Struck ingo at ingostruck.de
Mon Jan 27 07:21:43 EST 2003


Hi Manavendra...

Welcome at OWASP!

I've been developing major parts of the WebScarab subproject, 95+ % of the 
OCL code and the VulnXML db application for the last year / last quarter 
respectively.

So here are my points of view regarding the 10 points you had in mind;
for some of them there are already some docs in the CVS repository
(module ocl: ocl/doc/DEVELOPMENT ocl/doc/PACKAGING).
I know that at least the filtering project adheres to the PACKAGING 
recommendation; the idea of digitally signing code files met some opposition.

> 1. Coding Standards
There is a tool to reformat java source files: org.owasp.tool.CodeFormat
All basic classes should come with extensive (j)unit test suites for "stable"
releases.

> 2. Code Review Checklist
I wrote two tools for code review: CodeSign / CodeVerify to track which
developers have reviewed any particular version of a (java) source.
Alas, some people disliked that idea, so maybe we have to invent something
else and/or better.

> 3. Release notes guidelines
There are no standards for that, since we do not really have "stable" releases
yet. I would propose at least a changelog and some short description of new
features. API changes between major releases should be noticed explicitly.

> > 4. Build Process guidelines
Some of us tried to promote apache maven as the build process.
However some of the active developers (actually David R and me) consider this 
to be an unnecessary overhead. For java projects ant is the mandatory build 
tool. For convenience a make setup may be provided. All other projects should 
use plain make.

> > 5. Release Process guidelines - including packaging (internal
> > (development
> > builds) as well as actual)
see PACKAGING; ocl, vulnxml, webscarab (to some extent, its a bit inactive)
and filters roughly adhere to it. Hopefully the portal will adhere to that too 
in some weeks.

> > 6. Delivery control checklist
sourceforge packaging; each project leader should assure that source
distributions will build and run properly after a plain download and that 
binary distributions will install properly.

> > 7. Technology-specific best practices
none available yet; for java things seem to be rather clear, other 
technologies do not have specific guidelines

> > 8. Bug reporting and tracking mechanism
sourceforge bug tracker

> > 9. Defect tracking mechanism
sourceforge bug tracker

> > 10. CVS access guidelines
sourceforge CVS access control; only active developers are allowed to submit
to the cvs directly. There is a tacit agreement to leave the other subprojects
(modules) alone.

That's my opinion / status so far...

Kind regards

Ingo

-- 
ingo at ingostruck.de
Use PGP: http://ingostruck.de/ingostruck.gpg with fingerprint
C700 9951 E759 1594 0807  5BBF 8508 AF92 19AA 3D24




More information about the OWASP-Leaders mailing list