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

Ingo Struck ingo at ingostruck.de
Tue Jan 28 11:33:41 EST 2003


Hi Manavendra...

> 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?
That's a hard one. :o)
There are some naming / packaging guidelines I strictly adhere to, but
I know that some of my arguments for doing it exactly that way are not so
very well understood commonly... 

> all code
> files 'look' the same and any developer should be able to take up the file
> and find his/her way around it.
Yeah... My experience shows that most higher-level coders are *very* unwilling
to leave their personal ancient customs. ;o)
Try it, but I guess you willl tilt at windmills. *g*

> > 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.
Try it out, it's checked in the OCL package.

> a commercial tool called JStyle, that has a quite configurable set of
Is there an open source counterpart for that?

> 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?
Of course.
I consider any packed *tar.gz source/binary distro to be kind of stable.
Developers should prefer anonymous CVS access anyway.
Dedicated developers will get a full CVS access.
Every project leader should assure that the released packages at least 
compile, install and run on a specific environment without serious troubles.

> 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?
Another should-be that is something to be worked out till 0.1 (stable)
:o)

> > > 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.
You just upload a package of any form (tgz, tar.bz2, rpm, jar or the like)
together with a revision information.
There is a possibility to attach a history (changelog) as well as a release
announcement to it.

> 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.
There is no reason to demonise re-invention of wheels.
Sometimes it works out that the reinventions beat the old wheels.
For me code review consists to a large extent of filtering out the bad ideas
and retaining the good ones (kind of evolutionary development).

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

> > > 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 :-)
You can post in the categories

  - Bugs ( 1 open / 5 total )
  - Support Requests ( 0 open / 1 total )
  - Patches ( 0 open / 0 total )
  - Feature Requests ( 2 open / 2 total )
  - Design and Tech Specs ( 0 open / 0 total )

If they do not suffice, you can add own tracker groups.
The SF tracker is a powerful tool if used properly.


> 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?
This is all implemented in SF.
You have different project member roles and you can control CVS access
to some extent as well.

Try to get familiar with it, I guess this can be rather useful.
:o)

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