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

Manavendra Gupta manavendrak at hotmail.com
Wed Jan 29 13:12:15 EST 2003


> 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...
I know it's a difficult proposition sometimes to get the developers agree
upon, and more importantly, follow them, but from what I've seen, all such
attempts are usually met with stringent opposition in the start, but usually
tapers down as you reason with them. In fact, those who are against it,
usually come with the best and most practical suggestions - and these are
the ones who'd point out the guidelines/naming conventions that are
impractical.

> > 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 know. Especially when they are well-settled and 'into the groove' and
the project is underway. But we need to start somewhere, right?

> > Hmm interesting. I'd love to have something like CodeSign/CodeVerify.
> Try it out, it's checked in the OCL package.
I'm gonna do just that, this weekend.


> > a commercial tool called JStyle, that has a quite configurable set of
> Is there an open source counterpart for that?
:-) Yes, there is - http://checkstyle.sourceforge.net/

> 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.
I agree. So assuming the project leader sets out to compile all the packages
together and something doesn't work, or has some dependency that only that
particular developer knows about who happens to be on a vacation at that
point of time, so what do we do? Or that the project leader did test the
release but it still resulted in an error. How do we minimize such
occurences? I know there is an assumption here - that such occurences have
happened at OWASP and that some of the leaders had to struggle sometimes. If
nobody has faced this, and we think it's a non-issue for us, I'd still
suggest to put some minimal checks and balances in the entire build/release
process.

> > 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)
:-) What do you suggest the approach should be?


> > > 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.
Alright, I get the general idea. I suggest we finalize on what should be
attached at least wtih each release, and the format of each such document.
What do you think?

> 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).
I differ on this - I always have :-). I still look at the assembly lines at
manufacturing companies and marvel at how they've been able to ensure the
exact same quality for each piece that rolls out. Why can software not do
that? Agreed, this would take away the joy of the craft, but it's painful to
find developers battling the same problems and reaching different solutions
in different time and effort expenditure.

> > sourceforge bug tracker
> > > I'm sorry I'm not familiar with it. Is this similar to bugzilla?
> > Very similar to that.
Thanks.

> > > 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.
Alright. I think we should have a category 'trouble tickets' or 'defects'
(or something else) that should be used to log all the bugs reported post
formal release.

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

Thank you. Let me have a look at it :-)

Best Regards,
Manav.




More information about the OWASP-Leaders mailing list