[openvas-announce] OpenVAS Dev Con 1

[Tim Brown]

Folks,

Since a new year has begun, it's time to break out those rusty coding skills 
(hopefully you'll have recovered from the holiday period) and get to work on 
turning OpenVAS into a shining gem.

To that end, a developers conference has been proposed in Germany on the 
openvas-discuss list and I'd love to see some of you folks in attendance.  
Now I know it's a long way for some of you to come so I've decided to sit 
down and make a few notes on what I will be discussing.

1) How to make contributing easy

In an ideal world, we could all sit back and as itches happen they get fixed, 
but this doesn't work.  Why?  Well, from talking to some of you, direction is 
required.  Now direction isn't a big interest of mine, but it really should 
be for those people intending to use it.  So I'd like to push an idea of mine 
that bugs.openvas.org becomes a far more direct part of how we operate.  I'm 
thinking that we publicise our bugs system as *the* way to contribute.  The 
system already has much of what we need, I think it's really that this hasn't 
been stated.

So what I'm thinking, we get OpenVAS to a working point.  Some of this has 
already been done but not committed but there is doubtless more to do.  Can 
anyone who is interested enough to try, attempt to build and use the copy of 
OpenVAS currently in CVS.

File bugs for everything and anything - the binaries should be renamed, there 
is no valid SSL certificate for signing plugins, there is a clash in the 
plugin name space between Tenable and potential OpenVAS plugins etc.  If you 
have the confidence, try to resolve the problem.  As I notice people opening 
bugs, I'll give them access to maintain them.  Having more access will allow 
you to upload patches, give additional feedback etc.

Whilst this is going on, we'll use the openvas-development list as an 
introduction service arranging time for those of us who are in a position to 
work on the code to investigate reported issues and resolve them as required.

Likewise, I can see a similar workflow developing for plugins.  So, if any of 
you have private pools you'd like to see integrated in, open an issue for 
each (or if you have hundreds, open one issue and make us smile/grimace at 
the work load).

2) How to become trusted and what this means

When I launched the idea of OpenVAS, I suggested I'd like to see the consensus 
model being used.  To that end, I propose that as people become active in 
developing OpenVAS their status is increase, not to give them greater power 
over the project, but to allow them to more gracefully maintain their work on 
the code base.  One way to do this would be to formally announce on 
openvas-development that we're intending to (for example) give someone commit 
access to CVS to provoke a debate as to whether this is agreeable.

3) How we work with the distribution maintainers

We've already had a few words with the Debian maintainer and had an ebuild 
submitted for Gentoo, but there is more we can surely do.  We'll attempt to 
iron out the build process and gauge the frequency we feel we can issue 
stable updates.

4) How bugs.openvas.org operates

The nitty gritty of how to administrate bugs.openvas.org.  Hopefully, amongst 
the group of individuals attending Dev Con 1 we'll find some people to give 
me a hand with maintaining it.

5) What features/bugs need dealing with

See point 1) - hell I'm hoping that we'll have some bugs to actually work on 
in time for the Dev Con, but that depends on you all.

Cheers,
Tim
-- 
Tim Brown, OpenVAS
<mailto:timb at openvas.org>
<http://www.openvas.org/>