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

Alex Russell alex at securepipe.com
Tue Jan 28 12:11:49 EST 2003


On Tue, 28 Jan 2003, Ingo Struck wrote:
>
> 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...

Well, to be fair, we've restructured almost all of the CVS directories
around your good suggestions.  That it's been harder to sell some of the
other guidelines (IMHO) shows the downsides (and potential) beneifits of
the loosely-coupled Open Source methodology. Ingo likely gets frustrated
with the rest of us as he's "gone pro" while the rest of us are just
trying to fill some big shoes as amatures.

> > 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'm very concerned about for a couple of resons:

	1.) it's _going_ to cause developer friction, no matter what we
	adopt
	2.) there are very few languages that don't already have some set of
	idiomatic formatting that professional developers of said language
	use.

Given those, I think we should give project leads latitude on their code
formatting requirements, but should say that all subprojects SHOULD
define some kind of formatting standard and stick to it. This provies us
with a way to bring truly wayward projects back into the fold while
giving projects the flexibility the distribute Open Source development
model requires.

OTOH, if we're suddenly graced with a Linus-like development god that is
willing to be involved with _everyone's_ minutia, then we might have a
hope of enforcing some central guidelines on this one. Until then, I
suggest we let projects move forward on their own and see if consensus
emerges.

Text processing tools are plentiful and easy to use should we come to
eventually need a common format, winning back alienated developers
isn't nearly as simple.

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

Are you suggesting a "release notes template" of sorts? (I'm not for or
against, just curious)

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

Agreed. While I think it can't hurt to ask developers to poke around in
the other OWASP projects before looking elsewhere, I'd kinda like to see
re-used code get reused out of merit, not just because it was "ours".

-- 
Alex Russell
alex at SecurePipe.com
alex at netWindows.org




More information about the OWASP-Leaders mailing list