Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[Samuli Seppänen]

David Sommerseth ha scritto:
> On 12/12/09 11:52, Samuli Seppänen wrote:
> >> FWIW using a good (rather than merely adequate) revision control
> >> system makes it much easier to keep the very latest code
> >> on-line and still perform regression tests, keep separate
> >> code branches for feature development, and so forth.
> >>   
> > Any suggestion which VCS would do the best job?
>
>
> Then I'll throw in my burning piece of wood to fire ;-) ... Well,
> discussing VCS'es is a really tricky thing, and sometimes can become
> more a religious war than a technical war.  Especially VCS discussions
> seems often to hit the nerve of emotions.  Just to make that clear, I do
> not want to contribute to a "religious" war, but purely look at the
> technical point of view.  But it is based on my experiences, and I
> admit, I have not tried all solutions.  I have strong opinions, but I
> don't mean to attack anyone with them.
>
> My experiences is mostly based on CVS, SVN and git.  Even though, I have
> barely touched Mercurial/hg.  And I'm not going to discuss CVS, as
> that's not a good solution at all, IMHO.  In addition, it's centralised,
> not distributed.
>
> I've been following the Apache Qpid project somewhat for sometime
> earlier.  At that time it was based on SVN, and to be honest, it was a
> nightmare to work with.  To get the commit log, it took over 10-15
> seconds or so.  To pull down the complete tree took over 30 minutes,
> with a very decent connection (8Mbit++).  I believe the reason is that
> it was over 65.000 commits in the tree.  Branching is also somewhat
> cumbersome, even though it do work.
>
> Then I've been working with the Linux kernel.  A git repository which is
> getting close to 7-800MB (haven't checked in a while), it contains
> several years of commit history (it goes back to the 2.6.13 kernel or
> so, iirc).  And it takes milliseconds to look into the commit log.
> Cloning the kernel is done in 10-15 minutes tops, on the same connection
> as Qpid via SVN.  Everyone can create their own branches (in
> milliseconds), and can easily provide patches suitable for mailing.  In
> fact, you can send the patches via mail directly if you configure things
> correctly.  You can use multiple remote repositories which you can
> track, and you merge in the remote branches how you like yourself.
>
> What that means:  Everyone will pull at least one public git tree, which
> James "ownes".  Then James will have his "inner circle" with, f.ex.
> three persons.  Each of these three persons have their own public git
> trees, at least public to James.  These persons retrieve patches for
> review either via mail, patch files or other remote trees.  They will
> merge in changes into their own trees and publish their tree.  James
> will then only need to pull these three trees and merge them, whichever
> way James likes.  And when James is happy, he pushes his tree out.  Now,
> the good thing - if this is done right, people who committed changes to
> their own local trees, and git their trees pulled somehow by someone
> else closer to James, they can pull James' tree and merge it, without
> have no conflicts.  In fact, they might even find their commit ID's
> staying the same (depending on how patch was merged in on the way to
> James' tree).
>
>
> And git *is* pretty *easy* to get started with /nowadays/ (it's many
> years since it was difficult to use and more "kernel oriented").  Coming
> from the world of CVS and SVN, it took me 2-3 hours to de-learn CVS/SVN
> and 30 minutes to learn the basic git stuff.  And now, I can hardly
> imagine anything else.  I even use it for non-source code stuff too now,
> whenever I need to track some changes, and it takes me less than 10
> seconds to get it ready for it (really!).
>
> A very good resource for learning git, is a book called "Pro Git" ...
> .  A video of Linus explaining his thoughts
> behind git, can be viewed here:
> 
>
>
> But if SVN is preferred by OpenVPN, I'll most probably make use of
> git-svn, which is a SVN client for git.  It at least speeds up things
> for me, even though there are some awkward things with this, trying to
> make git stuff out of SVN, as that's not always easy due to the very
> different way of VCS designs ... but it do work somehow, and when the
> cloning is done - it is very fast again.
>
> So for me, git is among the greatest VCS' and, IMO, superior to SVN ...
> and I would therefore recommend git.  But it's not the only solution.
>
>
> kind regards,
>
> David Sommerseth
Any objections to GIT? If not, we should consider using that as our
primary future VCS. That is, when we can agree upon a new development
model that benefits from using it. I definitely need to delearn my SVN
skills, too, and start digging into GIT.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/09 00:16, James Yonan wrote:
>> 
>> However, it _could_ be a requirement that all patches be submitted
>> with documentation.  If not, I can't see how you'd want to
>> include any functional changes without also having documentation
>> so somebody else would have to be gotten to document the patch.
>> This is obviously up to whomever reviews the patches.
>> 

I would strongly recommend good commit comments from the persons
providing patches.  This should contain a description of what is changed
and why.  If the change is complex, it should also describe how the
patch fixes the issue.  On smaller or simpler patcher, this might
usually be enough.  But on bigger changes, especially with more code
being added to OpenVPN, the code itself should also have good and
descriptive comments as well.  What is obvious for the developer writing
the patch in that moment, might not be so obvious for a different
developer a few years later on.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkskCncACgkQDC186MBRfrr13wCghI5YuFCy3ihi7akjxm/1k4wi
QzgAoJgRMSizsfvhw76TKBCI6PI6/M/q
=DOcZ
-END PGP SIGNATURE-

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/12/09 11:52, Samuli Seppänen wrote:
>> FWIW using a good (rather than merely adequate) revision control
>> system makes it much easier to keep the very latest code
>> on-line and still perform regression tests, keep separate
>> code branches for feature development, and so forth.
>>   
> Any suggestion which VCS would do the best job?
> 

Then I'll throw in my burning piece of wood to fire ;-) ... Well,
discussing VCS'es is a really tricky thing, and sometimes can become
more a religious war than a technical war.  Especially VCS discussions
seems often to hit the nerve of emotions.  Just to make that clear, I do
not want to contribute to a "religious" war, but purely look at the
technical point of view.  But it is based on my experiences, and I
admit, I have not tried all solutions.  I have strong opinions, but I
don't mean to attack anyone with them.

My experiences is mostly based on CVS, SVN and git.  Even though, I have
barely touched Mercurial/hg.  And I'm not going to discuss CVS, as
that's not a good solution at all, IMHO.  In addition, it's centralised,
not distributed.

I've been following the Apache Qpid project somewhat for sometime
earlier.  At that time it was based on SVN, and to be honest, it was a
nightmare to work with.  To get the commit log, it took over 10-15
seconds or so.  To pull down the complete tree took over 30 minutes,
with a very decent connection (8Mbit++).  I believe the reason is that
it was over 65.000 commits in the tree.  Branching is also somewhat
cumbersome, even though it do work.

Then I've been working with the Linux kernel.  A git repository which is
getting close to 7-800MB (haven't checked in a while), it contains
several years of commit history (it goes back to the 2.6.13 kernel or
so, iirc).  And it takes milliseconds to look into the commit log.
Cloning the kernel is done in 10-15 minutes tops, on the same connection
as Qpid via SVN.  Everyone can create their own branches (in
milliseconds), and can easily provide patches suitable for mailing.  In
fact, you can send the patches via mail directly if you configure things
correctly.  You can use multiple remote repositories which you can
track, and you merge in the remote branches how you like yourself.

What that means:  Everyone will pull at least one public git tree, which
James "ownes".  Then James will have his "inner circle" with, f.ex.
three persons.  Each of these three persons have their own public git
trees, at least public to James.  These persons retrieve patches for
review either via mail, patch files or other remote trees.  They will
merge in changes into their own trees and publish their tree.  James
will then only need to pull these three trees and merge them, whichever
way James likes.  And when James is happy, he pushes his tree out.  Now,
the good thing - if this is done right, people who committed changes to
their own local trees, and git their trees pulled somehow by someone
else closer to James, they can pull James' tree and merge it, without
have no conflicts.  In fact, they might even find their commit ID's
staying the same (depending on how patch was merged in on the way to
James' tree).


And git *is* pretty *easy* to get started with /nowadays/ (it's many
years since it was difficult to use and more "kernel oriented").  Coming
from the world of CVS and SVN, it took me 2-3 hours to de-learn CVS/SVN
and 30 minutes to learn the basic git stuff.  And now, I can hardly
imagine anything else.  I even use it for non-source code stuff too now,
whenever I need to track some changes, and it takes me less than 10
seconds to get it ready for it (really!).

A very good resource for learning git, is a book called "Pro Git" ...
.  A video of Linus explaining his thoughts
behind git, can be viewed here: 


But if SVN is preferred by OpenVPN, I'll most probably make use of
git-svn, which is a SVN client for git.  It at least speeds up things
for me, even though there are some awkward things with this, trying to
make git stuff out of SVN, as that's not always easy due to the very
different way of VCS designs ... but it do work somehow, and when the
cloning is done - it is very fast again.

So for me, git is among the greatest VCS' and, IMO, superior to SVN ...
and I would therefore recommend git.  But it's not the only solution.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksj3OAACgkQDC186MBRfrqZxQCePKq0pY08mFPO3P06iTBsNGiM
AT8An02285FHVtdgy8+hB/ey/yRk4/KL
=T/mx
-END PGP SIGNATURE-

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[Samuli Seppänen]

> Via public discussion.  Who wants to submit a patch when it
> just disappears without comment.  Public discussion has been
> sorely lacking in the past.
>   
I can't comment on how patches have been handled in the past, but not
discussing and including them is a sure way to demotivate people.
>>>  Even
>>>   
>> patches
>> 
>>> these people write themselves should be posted to the openvpn-devel
>>>   
>> list
>> 
>>> (or other another more suitable one).  That way, more eyes can pay
>>> attention and raise awareness if something seems to be wrong or
>>>   
>> needs to
>> 
>>> be discussed.
>>>   
>
> Absolutely.  Public discussion of all submitted patches is essential.
>
> When you can commit to public discussion of submitted patches
> then I'll re-send at least one.  (Something very minor.)
>   
I agree that all developers should be treated equal and use the same
tools for their work. I don't personally like when people do things 
behind my back. Especially when the actions affects me somehow or when
it's clear I could have provided useful feedback. In the long run this
behavior leads to mistrust - "them" and "us" mentality. This is harmful
in any social relations, not just in OSS projects.
>> The SVN repository URL's are here:
>>
>> http://www.openvpn.net/index.php/open-source/documentation/
>> miscellaneous/subversion-repository.html
>>
>> I checked the logs and last update in 2.1 branch was from 2009-11-20,
>> so
>> it's probably 100% up-to-date. I agree with you for the most part.
>> Beaker sounds interesting, as I guess OpenVPN probably lends itself
>> well
>> to automated testing. 
>> 
>
> Are you saying that there has been no development on OpenVPN since
> 2009-11-20, approximately 20 days ago?  That seems a long time
> for James to have done no work on the code or documentation.
>   
I have to admit I do not know. I do know that James is swamped with work
and hence is unable to pay enough attention to the project. This is
something I'll be discussing with him. And the primary reason I
initiated this discussion. I'll try to help him out of his deadlock
situation which is hurting everybody.
> A public revision control repository means that the public gets
> to see all the changes as they are committed.  It does not mean
> that we get to see the code only at arbitrary release points.
>   
Agreed. However, if you take a look at the SVN logs each atomic change
(not just release points) is listed.
> There are 2 reasons for this.  The first is trust and transparency.
> We want to see where the code is going as it gets there so
> we can make our plans.  The second is to assist the people who
> review submitted patches.  Submitted patches should, by
> strong preference, be against the very latest version
> of the code.  This keeps merge conflicts, and related bugs,
> to a minimum and makes the job of reviewing patches much
> easier.
>   
I agree. Discussing and merging patches in a timely manner is essential.
As is an up-to-date development tree.
> If you don't have a public version of the latest development
> code you can't be said to be running an open project.
>
> FWIW using a good (rather than merely adequate) revision control
> system makes it much easier to keep the very latest code
> on-line and still perform regression tests, keep separate
> code branches for feature development, and so forth.
>   
Any suggestion which VCS would do the best job?

> What's the real policy regards the SVN repository and
> what are the concerns that have driven this policy?
>   
I'd guess the decision was not driven by any conscious policy.

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[James Yonan]

Karl O. Pinc wrote:

On 12/10/2009 04:39:57 AM, Samuli Seppänen wrote:

David Sommerseth ha scritto:



I believe James have received several patches in the past from

people on
the mailing list - or directly. 



They will either include patches into their own source

trees, or

kick them back to be reworked or cancelled completely.

Patches which are accepted will then be sent to James for a final

review

and inclusion.  If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was

rejected
and how to make it more acceptable for inclusion.  If James can 

take
the

time to bring this discussion on the mailing list directly himself

in

these cases, that would bring the needed transparency.  Further, it
should hopefully not happen too often, as James' "inner circle"

should

already have made sure it is suitable for inclusion.


Via public discussion.  Who wants to submit a patch when it
just disappears without comment.  Public discussion has been
sorely lacking in the past.


 Even

patches

these people write themselves should be posted to the openvpn-devel

list

(or other another more suitable one).  That way, more eyes can pay
attention and raise awareness if something seems to be wrong or

needs to

be discussed.


Absolutely.  Public discussion of all submitted patches is essential.

When you can commit to public discussion of submitted patches
then I'll re-send at least one.  (Something very minor.)

Another topic which is needed to be included is documentation.  

This

would be to organise the documentation and make sure all features

are

documented, review documentation to make sure it works as expected

etc,
etc.  This part do not necessarily require any coding skills at 

all.


However, it _could_ be a requirement that all patches be submitted
with documentation.  If not, I can't see how you'd want to
include any functional changes without also having documentation
so somebody else would have to be gotten to document the patch.
This is obviously up to whomever reviews the patches.



What I do see as much more urgent is actually a better distributed
VCS/RCS.  I believe SVN is used now - but I don't recall where I

found

the URL for it (and I have lost now, I believe).  There's also a

rather

outdated CVS tree on sourceforge.net.  This needs to be cleaned up,

and

a publicly available source tree must be made available.



David Sommerseth



The SVN repository URL's are here:

http://www.openvpn.net/index.php/open-source/documentation/
miscellaneous/subversion-repository.html

I checked the logs and last update in 2.1 branch was from 2009-11-20,
so
it's probably 100% up-to-date. I agree with you for the most part.
Beaker sounds interesting, as I guess OpenVPN probably lends itself
well
to automated testing. 


Are you saying that there has been no development on OpenVPN since
2009-11-20, approximately 20 days ago?  That seems a long time
for James to have done no work on the code or documentation.

A public revision control repository means that the public gets
to see all the changes as they are committed.  It does not mean
that we get to see the code only at arbitrary release points.

There are 2 reasons for this.  The first is trust and transparency.
We want to see where the code is going as it gets there so
we can make our plans.  The second is to assist the people who
review submitted patches.  Submitted patches should, by
strong preference, be against the very latest version
of the code.  This keeps merge conflicts, and related bugs,
to a minimum and makes the job of reviewing patches much
easier.

If you don't have a public version of the latest development
code you can't be said to be running an open project.

FWIW using a good (rather than merely adequate) revision control
system makes it much easier to keep the very latest code
on-line and still perform regression tests, keep separate
code branches for feature development, and so forth.

What's the real policy regards the SVN repository and
what are the concerns that have driven this policy?


I wanted to respond to some of the points brought up, as they are good 
points.


First of all, the patch policy: fundamentally, we have to balance two 
conflicting goals:


One the one hand people expect OpenVPN to be rock-solid in both 
stability and security.  In order to maintain this standard of quality, 
there needs to be a rigorous process of patch vetting.  On the other 
hand, as an open source project, OpenVPN needs to be transparent and 
open to contributions from the community.


It can be a challenge to balance these goals.  And certainly in the 
lead-up to the release of 2.1 there was a long period of time that we 
had to lean strongly towards (1) to ensure that 2.1 final would be solid.


I think it's great that Samuli Seppänen has come forward to serve as the 
OpenVPN Community Manager -- one of our key goals here is to create a 
community structure around the patch 

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[Samuli Seppänen]

David Sommerseth ha scritto:
> On 09/12/09 11:54, Samuli Seppänen wrote:
> >> On Mon, Dec 07, 2009 at 12:25:09PM +0200, Samuli Seppänen wrote:
> >>   
> >>> Hello everybody,
> >>>
> >>> I'm the newly appointed community manager for OpenVPN Technologies. I
> >>> will be acting as a liaison between OpenVPN community and OpenVPN
> >>> Technologies. I will help us (the company) make our development more
> >>> community-oriented, e.g. by providing the tools and making development
> >>> 
> >> [snip]
> >>
> >> Hi Samuli,
> >>
> >> Welcome! I hope the communication with the community will improve with
> >> your help. In this regard, I'd like to know if it's in your duties to
> >> deal with bug reports/feature requests, since there's a bunch [1] of
> >> them reported in the Debian Bug Tracking System.
> >>
> >> Please don't hesitate to contact me if you need my help at any time.
> >>
> >> Thanks,
> >>
> >> Alberto
> >>
> >> [1]
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags:upstream;dist=unstable;package=openvpn
> >>
> >>   
> > Hi Gonzales,
>
> > We're definitely committed to making OpenVPN as close to a true
> > community project as possible. This will require rethinking how OpenVPN
> > development is done. In theory it's easy: just delegate responsibility
> > to community members. The problem is how to keep the work organized so
> > that the new development process actually produces better (and faster)
> > results. This is something I've already discussed with some community
> > members. One option mentioned was the Linux kernel model. In our case,
> > James would be Linus who (mostly) reviews other people's patches and
> > applies them.
>
> I strongly encourages such a model.  This might be not needed
> information what I'm providing here now, but I'll add it for those who
> are don't know or just are interested in one approach of how such a
> community can work.  This is purely my own experiences with working with
> such communities.
>
> I believe James have received several patches in the past from people on
> the mailing list - or directly.  At least I hope he keeps an eye on the
> mailing list and might have an idea who might be potential candidates to
> help out in his "inner circle".  Anyhow, it is important that this
> circle includes people which he can trust 100%.  Each of these persons
> (maybe they will concentrate on different parts of the OpenVPN code, but
> this they need to arrange between themselves) will then pay attention to
> patches which hits their segment/interest field and they can validate
> these patches.  It don't need to be many persons, it can be one or it
> can be fifteen, the amount is not that important, especially not right
> now.  The important part is that there are someone who reviews and keeps
> an open dialogue with the community and also have a good connection with
> James.  They will either include patches into their own source trees, or
> kick them back to be reworked or cancelled completely.
>
> Patches which are accepted will then be sent to James for a final review
> and inclusion.  If James don't like it, it must be discussed on the
> mailing list so that everyone can see and understand why it was rejected
> and how to make it more acceptable for inclusion.  If James can take the
> time to bring this discussion on the mailing list directly himself in
> these cases, that would bring the needed transparency.  Further, it
> should hopefully not happen too often, as James' "inner circle" should
> already have made sure it is suitable for inclusion.
>
> These "inner circle" people do not need to be "community members".  I
> don't know how big the OpenVPN Technologies Inc. company is, but it can
> even be people from here.  But it is important that 1) James trust these
> persons ultimately and will be willing to grant them more privileges, 2)
> that these people are active and visible in the community.  Even patches
> these people write themselves should be posted to the openvpn-devel list
> (or other another more suitable one).  That way, more eyes can pay
> attention and raise awareness if something seems to be wrong or needs to
> be discussed.
>
> This part is, IMHO, the most important part to get implemented first.
> The rest will basically come as a result of this.
>
> > I think we'd also need to build teams for various
> > purposes, e.g. for QA, packaging, different GUI's... this would enable
> > easy participation in OpenVPN development, whether you're a coder or
> > not. This is something Ubuntu has done pretty well.
>
> Agreed, but this will need to come a litter bit later on.  IMHO, get the
> development cycle in shape then QA and packaging/release engineering
> must come immediately afterwords.  QA can most probably be done in
> cooperation with the bigger Linux distributors as well.  The Fedora
> community is working hard on a big testing framework called Beaker,
> which is aimed at automatic testing of software.  (I even think Beaker
> might 

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/12/09 11:54, Samuli Seppänen wrote:
> 
>> On Mon, Dec 07, 2009 at 12:25:09PM +0200, Samuli Seppänen wrote:
>>   
>>> Hello everybody,
>>>
>>> I'm the newly appointed community manager for OpenVPN Technologies. I
>>> will be acting as a liaison between OpenVPN community and OpenVPN
>>> Technologies. I will help us (the company) make our development more
>>> community-oriented, e.g. by providing the tools and making development
>>> 
>> [snip]
>>
>> Hi Samuli,
>>
>> Welcome! I hope the communication with the community will improve with
>> your help. In this regard, I'd like to know if it's in your duties to
>> deal with bug reports/feature requests, since there's a bunch [1] of
>> them reported in the Debian Bug Tracking System.
>>
>> Please don't hesitate to contact me if you need my help at any time.
>>
>> Thanks,
>>
>> Alberto
>>
>> [1] 
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags:upstream;dist=unstable;package=openvpn
>>
>>   
> Hi Gonzales,
> 
> We're definitely committed to making OpenVPN as close to a true
> community project as possible. This will require rethinking how OpenVPN
> development is done. In theory it's easy: just delegate responsibility
> to community members. The problem is how to keep the work organized so
> that the new development process actually produces better (and faster)
> results. This is something I've already discussed with some community
> members. One option mentioned was the Linux kernel model. In our case,
> James would be Linus who (mostly) reviews other people's patches and
> applies them. 

I strongly encourages such a model.  This might be not needed
information what I'm providing here now, but I'll add it for those who
are don't know or just are interested in one approach of how such a
community can work.  This is purely my own experiences with working with
such communities.

I believe James have received several patches in the past from people on
the mailing list - or directly.  At least I hope he keeps an eye on the
mailing list and might have an idea who might be potential candidates to
help out in his "inner circle".  Anyhow, it is important that this
circle includes people which he can trust 100%.  Each of these persons
(maybe they will concentrate on different parts of the OpenVPN code, but
this they need to arrange between themselves) will then pay attention to
patches which hits their segment/interest field and they can validate
these patches.  It don't need to be many persons, it can be one or it
can be fifteen, the amount is not that important, especially not right
now.  The important part is that there are someone who reviews and keeps
an open dialogue with the community and also have a good connection with
James.  They will either include patches into their own source trees, or
kick them back to be reworked or cancelled completely.

Patches which are accepted will then be sent to James for a final review
and inclusion.  If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was rejected
and how to make it more acceptable for inclusion.  If James can take the
time to bring this discussion on the mailing list directly himself in
these cases, that would bring the needed transparency.  Further, it
should hopefully not happen too often, as James' "inner circle" should
already have made sure it is suitable for inclusion.

These "inner circle" people do not need to be "community members".  I
don't know how big the OpenVPN Technologies Inc. company is, but it can
even be people from here.  But it is important that 1) James trust these
persons ultimately and will be willing to grant them more privileges, 2)
that these people are active and visible in the community.  Even patches
these people write themselves should be posted to the openvpn-devel list
(or other another more suitable one).  That way, more eyes can pay
attention and raise awareness if something seems to be wrong or needs to
be discussed.

This part is, IMHO, the most important part to get implemented first.
The rest will basically come as a result of this.

> I think we'd also need to build teams for various
> purposes, e.g. for QA, packaging, different GUI's... this would enable
> easy participation in OpenVPN development, whether you're a coder or
> not. This is something Ubuntu has done pretty well. 

Agreed, but this will need to come a litter bit later on.  IMHO, get the
development cycle in shape then QA and packaging/release engineering
must come immediately afterwords.  QA can most probably be done in
cooperation with the bigger Linux distributors as well.  The Fedora
community is working hard on a big testing framework called Beaker,
which is aimed at automatic testing of software.  (I even think Beaker
might support Windows testing in the future as well, but I have not
checked it out)  Other distroes might have similar systems as well.  The
important thing is to