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

Manavendra Gupta manavendrak at hotmail.com
Tue Jan 28 19:20:46 EST 2003


Hi Ingo,

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

Wow, that's something!

> 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.
I apologize I haven't been able to look at CodeFormat. Yet. I agree about
the basic classes being shipped with (j)unit test cases and tools to format
the code, but do we not need a set of guidelines about naming conventions
(for methods, classes, public variables, statics, etc), the guidelines about
imports, variable declaration guidelines, etc? I have a quite a long
checklist that I use for my other (commercial) projects and I am trying to
convert it to DocBook format so I can share it with everyone. What do you
think? To control and maintain projects over a longer period, I believe, we
need to have a set of guidelines that ensures (as I said before) all code
files 'look' the same and any developer should be able to take up the file
and find his/her way around it.

> > 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.
Hmm interesting. I'd love to have something like CodeSign/CodeVerify. Maybe
we can have the two of them coupled together. Talking about tools, there is
a commercial tool called JStyle, that has a quite configurable set of
rules/guidelines that the code can be tested against. Perhaps we can use it
(or build something like that) and a set of guidelines that everyone agrees
upon?


> 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.
I understand where you are coming from. My point being, even if the releases
are not stable, they should still follow a certain pre-defined process. Each
release, stable or not, is a work packet, that adds up in the whole picture
somewhere.  Too many times, we see a file being missed here and there, or a
file of the wrong version being sent in the release, etc. On top of a
changelog, short description of features, API changes between major
releases, we should also have the list of changes required/assumed/expected
on the environment/database. Further, this very document that contains the
changelog, list of features, etc should be a "standard" one. Maybe, some of
what I said might not be applicable here, but I hope I am able to convey the
general idea?


> > 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.
Makes sense. I'm awaiting a response from others on the list. Lets wait and
see what others think.


> > 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.
How do we proceed from different builds to a release? Who ascertains and
authorizes it? What is set of tests that we do to ensure this (or these)
build(s) should now be formed the part of a release? What and how do we
package and document with each release? Do we mention the
bugs/issues/defects fixed? The list of files changed?


> > 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.
I'm sorry, I am not familiar with sourceforce packaging. Please give me some
time to loo at it.

> > 7. Technology-specific best practices
> none available yet; for java things seem to be rather clear, other
> technologies do not have specific guidelines
This isn't high priority, but as we move forward, we need to ensure
different projects are not re-inventing the wheel - which brings up another,
parallel issue - that of code re-use. But before I jump to that, with the
community of developers (or enthusiasts) that we have, I'm similar battles
are being fought across projects and disparate victories ensue. These best
practices (for java to begin with as you said), will help provide insights
into situations faced by others, without actually reaching those hurdles.

> > 8. Bug reporting and tracking mechanism
> sourceforge bug tracker
I'm sorry I'm not familiar with it. Is this similar to bugzilla?

> > 9. Defect tracking mechanism
> sourceforge bug tracker
Do we want to have the same system for reporting errors as well as defects?
Perhaps, I've spent too much time on commercial projects :-)

> > 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.
Again, I butted in from a sort-of commercial project angle - there are
instances where only a certain number of people are given the right to
create files, some to view the files only (the QA/review teams, etc) and
while others have permissions to create projects, etc. Perhaps this is not
what we need. What do you/others think?





More information about the OWASP-Leaders mailing list