[Openvpn-devel] Introducing OpenVPN Community Manager

[Openvpn-devel] Introducing OpenVPN Community Manager

[@ 2009-12-07 10:25 UTC (permalink / raw)]

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
more transparent, so that both the community and the company benefit. To
accomplish these goals I need to work with you. I'll keep my own work as
transparent as possible so that you can constantly provide feedback
(positive or negative). Also, if you have any suggestions let me know -
preferably using the OpenVPN mailinglists. You can also talk to me
("mattock") in the OpenVPN IRC channel during daytime (in EET/EEST
timezone).

Now onto more concrete topics... I'm currently looking into community
projects around OpenVPN. I've so far found 14 different OpenVPN GUI
projects and two forum/wiki projects. I've listed them here:

 http://users.utu.fi/sjsepp/openvpn_community_projects.html

Do you know of other OpenVPN-related projects?

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


PS. I'm also the project leader for the fully community-driven OpenVPN
ALS project (http://sourceforge.net/projects/openvpn-als), which I
forked from 3sp's SSL-Explorer in May 2008. In a nutshell, ALS is a
web-based application layer SSL VPN written in Java(EE). For more
information about ALS, see our project Wiki:

http://sourceforge.net/apps/trac/openvpn-als/wiki

If you want more information about ALS just drop me a mail.

Re: [Openvpn-devel] Introducing OpenVPN Community Manager

[Yevgeny Kosarzhevsky]

Hi,

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.
>    
Welcome!
> Now onto more concrete topics... I'm currently looking into community
> projects around OpenVPN. I've so far found 14 different OpenVPN GUI
> projects and two forum/wiki projects. I've listed them here:
>
>   http://users.utu.fi/sjsepp/openvpn_community_projects.html
>
> Do you know of other OpenVPN-related projects?
>    
http://sourceforge.net/projects/ovpnp/

Re: [Openvpn-devel] [Openvpn-users] Introducing OpenVPN Community Manager

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/12/09 13:36, Laurent GUERBY wrote:
> GNOME NetworkManager has a dialog box to manage openvpn connections,
> I don't know if that counts :).

That's most probably the "NetworkManager OpenVPN plugin".  GNOME NM do
not have a "native" OpenVPN implementation, but relies on VPN plug-ins.
 There's even a plug-in for vpnc as well.


kind regards,

David Sommerseth


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

iEYEARECAAYFAksc/aoACgkQDC186MBRfrooUQCfUywN2EhepIZf6pVs+DaFTpQq
I/wAmgK3q2AHFy9LImESXxQbFH8AsVmZ
=H9sh
-----END PGP SIGNATURE-----

Re: [Openvpn-devel] [Openvpn-users] Introducing OpenVPN Community Manager

[@ 2009-12-07 13:16 UTC (permalink / raw)]

David Sommerseth ha scritto:
> On 07/12/09 13:36, Laurent GUERBY wrote:
> > GNOME NetworkManager has a dialog box to manage openvpn connections,
> > I don't know if that counts :).
>
> That's most probably the "NetworkManager OpenVPN plugin".  GNOME NM do
> not have a "native" OpenVPN implementation, but relies on VPN plug-ins.
>  There's even a plug-in for vpnc as well.
>
>
> kind regards,
>
> David Sommerseth
>

That's correct. I updated my list of OpenVPN projects and it's starting
to become quite exhausting... see for yourself. I'm probably only
halfway through:

http://users.utu.fi/sjsepp/openvpn_community_projects.html

Lot of the work is redundant, but on the positive side there is a lot of
activity around OpenVPN.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

Re: [Openvpn-devel] Introducing OpenVPN Community Manager

[Michele Baldessari]

On Mon, 2009-12-07 at 13:01 +0200, Yevgeny Kosarzhevsky wrote:
> > Now onto more concrete topics... I'm currently looking into community
> > projects around OpenVPN. I've so far found 14 different OpenVPN GUI
> > projects and two forum/wiki projects. I've listed them here:
> >
> >   http://users.utu.fi/sjsepp/openvpn_community_projects.html
> >
> > Do you know of other OpenVPN-related projects?

http://sourceforge.net/projects/securepoint/

hth,
Michele

Re: [Openvpn-devel] Introducing OpenVPN Community Manager

[@ 2009-12-07 22:25 UTC (permalink / raw)]

On Monday 07 December 2009 11:25:09 Samuli Seppänen wrote:

> Do you know of other OpenVPN-related projects?

JuanJo's IPv6-patches which are used in Gentoo Portage and AFAIR Debian sid. 
Ubuntu packages are also available.

http://github.com/jjo/openvpn-ipv6 

Marcel

Re: [Openvpn-devel] [Openvpn-users] Introducing OpenVPN Community Manager

[@ 2009-12-08 10:57 UTC (permalink / raw)]

Hi all,

Many thanks to all of you for providing links to OpenVPN-related
projects, keep 'em coming. Some are still missing, but here's the most
recent list:

http://users.utu.fi/sjsepp/openvpn_community_projects.html

All the best,

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc





Samuli Seppänen ha scritto:
> David Sommerseth ha scritto:
>   
>> On 07/12/09 13:36, Laurent GUERBY wrote:
>>     
>>> GNOME NetworkManager has a dialog box to manage openvpn connections,
>>> I don't know if that counts :).
>>>       
>> That's most probably the "NetworkManager OpenVPN plugin".  GNOME NM do
>> not have a "native" OpenVPN implementation, but relies on VPN plug-ins.
>>  There's even a plug-in for vpnc as well.
>>
>>
>> kind regards,
>>
>> David Sommerseth
>>
>>     
>
> That's correct. I updated my list of OpenVPN projects and it's starting
> to become quite exhausting... see for yourself. I'm probably only
> halfway through:
>
> http://users.utu.fi/sjsepp/openvpn_community_projects.html
>
> Lot of the work is redundant, but on the positive side there is a lot of
> activity around OpenVPN.
>
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
>
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing. 
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>   

Re: [Openvpn-devel] [Openvpn-users] Introducing OpenVPN Community Manager

[@ 2009-12-09 8:55 UTC (permalink / raw)]

Nick Owen ha scritto:
> 2009/12/7 Samuli Seppänen <samuli@...515...>:
>   
>> 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
>> more transparent, so that both the community and the company benefit. To
>> accomplish these goals I need to work with you. I'll keep my own work as
>> transparent as possible so that you can constantly provide feedback
>> (positive or negative). Also, if you have any suggestions let me know -
>> preferably using the OpenVPN mailinglists. You can also talk to me
>> ("mattock") in the OpenVPN IRC channel during daytime (in EET/EEST
>> timezone).
>>
>> Now onto more concrete topics... I'm currently looking into community
>> projects around OpenVPN. I've so far found 14 different OpenVPN GUI
>> projects and two forum/wiki projects. I've listed them here:
>>
>>  http://users.utu.fi/sjsepp/openvpn_community_projects.html
>>
>> Do you know of other OpenVPN-related projects?
>>     
>
> Samuli:
>
> I see you have WiKID Systems listed.  Thanks!
>
> Here's a link for a WiKID/OpenVPN  tutorial:
> http://www.wikidsystems.net/support/wikid-support-center/how-to/using-wikid-strong-authentication-with-openvpn/
>
> We also have a how-to for ssl-explorer back from before the
> Adito/OpenVPN-ALS fork.
> http://www.wikidsystems.net/support/wikid-support-center/how-to/how-to-secure-an-ssl-vpn-with-one-time-passcodes-and-mutual-authentication/.
> I haven't had time to update that, though it is on the to-do.  This
> setup takes advantage of WiKID's mutual https authentication to
> validate the SSL cert for the user, providing protection against
> network-based MITM attacks.
>
> In the long run, I'd be interested in a direct WiKID/OpenVPN-ALS
> plugin and to perhaps a combined WiKID token/openvpn client.
>
> Great work!
>
> Nick
>   
Hi Nick,

Just drop a mail to openvpn-als-devel if you want to start developing an
OpenVPN ALS WikID plugin:

https://lists.sourceforge.net/mailman/listinfo/openvpn-als-devel

You can also visit our IRC channel (#adito) at freenode.net. As ALS has
RADIUS support (like SSL-E), binding WikiD and ALS should be no problem.

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

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

[@ 2009-12-09 10:54 UTC (permalink / raw)]

> 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 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. Currently we're
lacking basic community services (e.g. forums, trackers, wiki,
[sub]project hosting), but we're working on that. However I think the
basic development model should be agreed upon before building any services.

Anyways, I'm very interested in any ideas on how to organize the project
in a more community-oriented fashion. So please let me know of any ideas
/ insights you might have.

-- 
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 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 make use of what is already existing.

Before a proper automated testing is in place, having a written and
publicly available "How to QA test" documentation is needed.  What
should be tested and how.  Define different testing phases (Tier-1,
Tier-2, etc) and what these testing phases needs to include.  Getting
involved in test testing part will require some development knowledge,
but not in-depth details of OpenVPN.

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.

> Currently we're
> lacking basic community services (e.g. forums, trackers, wiki,
> [sub]project hosting), but we're working on that. However I think the
> basic development model should be agreed upon before building any services.

Forums and wikis exists, even though unofficial ones.  But all these
services are also available via sourceforge.net as well.  Anyhow, I
agree this is not so urgent.

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.

I'm tracking OpenVPN releases by importing the source tar balls into my
own git tree, to be sure I can update my OpenVPN patch quick and
efficient.  But I'd like to do this based on a publicly available source
tree, which is tagged with the releases packaged and made available.  I
don't care too much what it is, but I hope it will not be anything worse
than SVN (like CVS).  But if another more modern and proper DVCS is
chosen, I'd applaud that!

The model I've suggested above, will work very well with git.  But I
know choosing/changing VCS is almost as brutal as a religion war, which
I don't want to neither support nor trigger.  But I do believe a better
DVCS (than CVS or SVN) is needed for this to work more flawlessly and
efficient, no matter what DVCS is chosen.  I just hope it will be an
Open Source based one.

And if James don't want to change it, fine! Just make SVN URLs publicly
and easily available.  Anyhow, when starting on the next version when
2.1 is finally released, it is a good time to at least consider the options.



kind regards,

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

iEYEARECAAYFAksfkf8ACgkQDC186MBRfrpgbwCgilrmlIuDmTbGjOQG0dYNqBcC
/L0AoJk+HfMXONEFBOviduXytx681/id
=s4BF
-----END PGP SIGNATURE-----

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

[@ 2009-12-10 10:39 UTC (permalink / raw)]

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 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 make use of what is already existing.
>
> Before a proper automated testing is in place, having a written and
> publicly available "How to QA test" documentation is needed.  What
> should be tested and how.  Define different testing phases (Tier-1,
> Tier-2, etc) and what these testing phases needs to include.  Getting
> involved in test testing part will require some development knowledge,
> but not in-depth details of OpenVPN.
>
> 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.
>
> > Currently we're
> > lacking basic community services (e.g. forums, trackers, wiki,
> > [sub]project hosting), but we're working on that. However I think the
> > basic development model should be agreed upon before building any
> services.
>
> Forums and wikis exists, even though unofficial ones.  But all these
> services are also available via sourceforge.net as well.  Anyhow, I
> agree this is not so urgent.
>
> 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.
>
> I'm tracking OpenVPN releases by importing the source tar balls into my
> own git tree, to be sure I can update my OpenVPN patch quick and
> efficient.  But I'd like to do this based on a publicly available source
> tree, which is tagged with the releases packaged and made available.  I
> don't care too much what it is, but I hope it will not be anything worse
> than SVN (like CVS).  But if another more modern and proper DVCS is
> chosen, I'd applaud that!
>
> The model I've suggested above, will work very well with git.  But I
> know choosing/changing VCS is almost as brutal as a religion war, which
> I don't want to neither support nor trigger.  But I do believe a better
> DVCS (than CVS or SVN) is needed for this to work more flawlessly and
> efficient, no matter what DVCS is chosen.  I just hope it will be an
> Open Source based one.
>
> And if James don't want to change it, fine! Just make SVN URLs publicly
> and easily available.  Anyhow, when starting on the next version when
> 2.1 is finally released, it is a good time to at least consider the
> options.
>
>
>
> kind regards,
>
> 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. Unlike, say, applications with rich user
interfaces. Anyways real human QA/testing is nevertheless necessary. I'm
sure there are professional testers in the community who could lead the
testing team.

I'll talk to James about these issues a.s.a.p. - unless he takes parts
in the conversation, that is :).

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

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

[Karl O. Pinc]

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?

Karl <kop@...1206...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

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 discussion and approval process 
that removes myself as a bottleneck.

Re: the SVN repository.

The policy on the SVN repository is the same as that of most open source 
projects: the repository is world-readable, and writable by trusted 
members of the development team.

The repository change history is fully transparent.  You can use this 
command to see every commit made to the repository since the OpenVPN 
project inception in 2002.

   svn log http://svn.openvpn.net/projects/openvpn/branches/BETA21

(note that now that 2.1 is final, this branch will be renamed to 
http://svn.openvpn.net/projects/openvpn/trunk in the near future)

James

Re: [Openvpn-devel] OpenVPN project organization

[Stefan Monnier]

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

That misses the main issue: you can reject most patches on some
stability ground, but then as a contributor I'd like to know how to
improve my patch to make it acceptable.

E.g. my "fqdn route with fqdn's that map to multiple IPs" patch (which
I consider to be a bug-fix rather than a feature addition) has been
somewhat discussed but only w.r.t the functionality, not the actual
code, so I have no idea what I need to do in order to have it
be accepted.  This is frustrating.

This said, as a maintainer of a Free Software package, I am quite aware
that giving responding to all contributions (let alone giving good
feedback) can be challenging.


        Stefan

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

[@ 2009-12-12 10:52 UTC (permalink / raw)]

> 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

[@ 2009-12-12 11:37 UTC (permalink / raw)]

Stefan Monnier ha scritto:
>> 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.
>>     
>
> That misses the main issue: you can reject most patches on some
> stability ground, but then as a contributor I'd like to know how to
> improve my patch to make it acceptable.
>   
> E.g. my "fqdn route with fqdn's that map to multiple IPs" patch (which
> I consider to be a bug-fix rather than a feature addition) has been
> somewhat discussed but only w.r.t the functionality, not the actual
> code, so I have no idea what I need to do in order to have it
> be accepted.  This is frustrating.
>
> This said, as a maintainer of a Free Software package, I am quite aware
> that giving responding to all contributions (let alone giving good
> feedback) can be challenging.
>
>
>         Stefan
>   
Very good points. The first challenge is reviewing patches. I guess many
problems can be spotted with a quick look on the patch. These problems
should communicated so that they can be fixed. And if the patch is
included, then we should communicate that, too. Otherwise the committer
might think his/her patch was rejected.

Now, if we want to maintain stability, we need some way to test the
patches. Automated tests could be used in many cases but building the
test cases takes time. In addition I don't think automated tests catch
nearly all problems, so manual testing is required. I'm not a specialist
in VCS systems but I guess a distributed VCS could help in this. What
are your thoughts on the testing procedures/tools? Fedora's Beaker suite
was mentioned earlier and it sounds interesting.

-- 
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 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" ...
<http://progit.org/book/>.  A video of Linus explaining his thoughts
behind git, can be viewed here: <http://www.youtube.com/watch?v=4XpnKHJAok8>


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

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/12/09 12:37, Samuli Seppänen wrote:
> Now, if we want to maintain stability, we need some way to test the
> patches. Automated tests could be used in many cases but building the
> test cases takes time. In addition I don't think automated tests catch
> nearly all problems, so manual testing is required. I'm not a specialist
> in VCS systems but I guess a distributed VCS could help in this. What
> are your thoughts on the testing procedures/tools? Fedora's Beaker suite
> was mentioned earlier and it sounds interesting.

Let's first give a little introduction of Beaker, so that nobody
believes it is something exceptionally which solves all the problems.

First of all Beaker is being built up now, it is quite a big project
consisting of a lot of modules which will communicate together.  I'm not
sure how far things are in the overall project, but I'll give a little
intro here about the concept.  Otherwise, beware that crucial modules of
Beaker might not be ready yet.

A Beaker installation is a big installation.  It is aimed at
automatically testing software on a broad variety of distributions and
provide a report of how that test ran.  And you will most probably need
quite some hardware to get this up and running.

First, Beaker have an inventory module.  Here hosts are registered into
a database with information about hardware and supported OS and
distributions.  Then there is a scheduler, which receives requests for
running particular tests (aka jobs).  The job scheduler then uses the
inventory to pick out the best suited boxes which are available to run
the test(s) on.  The inventory is then instructed by the job scheduler
to do a scratch installation of an assigned OS/distribution.  As a part
of this OS installation, it will install the defined test scripts on the
box, run all the tests, collect the results and release the box back to
the inventory again.

I know the inventory part is pretty much up'n'running, and I believe the
job scheduler is getting more and more ready.  (It's a while since I
checked that status) ... so this needs to be checked out.  But as you
see, some hardware is needed, even though I believe Beaker do (or at
least will in the future) support virtual hosts as well.  Then the test
script given to the job scheduler will define who each of the virtual
hosts will be installed as well.

The good thing about the Beaker framework is that you usually just need
to install a few packages on your own local box to develop and run the
test scripts locally.  When the script is ready, it's packaged and sent
to the tests repository in Beaker.  So it is also possible to run Beaker
in a very small scale for test development.

You can also browse the test repository via web, and ask for certain
tests to be run.  The test script defines which packages is needed to
run the test, and the software being tested needs to be put into a
special repository, where the script will download and install the
package, as a part of the test run.

There's also features like multi-host tests, where more hosts are
involved to run one single test, to test communication between hosts,
etc.  So this is the direction Beaker is headed.


So, back to the topic ... some of these things might already have been
thought of by the QA team and might even be implemented.  But as I don't
know how the OpenVPN team does the QA work, I'll share my thoughts here
... how I see the "perfect" world :)

Anyhow, you can use such an infrastructure as Beaker to test patches, as
you vaguely indicated, Samuli.  But Beaker is usually much more suitable
for testing an already compiled and packaged piece of software before
shipment.  But of course, it's all scripts, and it can also download
source code and compile it too.  But I'm not sure how well it will
perform under these conditions, it might be better with another approach.

However, I would recommend a setup which only a few of the developers
James will cooperate closely with, including James, will have access to.
 This setup will do a build of the source code at a given commit, and
run a standard test suite, aimed at the first stage of the development
cycle.  This should test for compilation issues (including warnings) and
report them to the developers.  It should run openvpn in a few different
modes, with different options to test generic functionality.  It might
support different test modes, so that the test script will take between
5 minutes and 30 minutes, it might even be a few different tests with
different run times.  This is only aimed at giving a quick indication on
how well the code is running.

Then when much more commits have been collected, a preliminary package
can be compiled and sent to a Beaker setup.  The tests here can be much
more comprehensive, and ideally should test all options and
configuration modes of OpenVPN.  One test should also be a performance
tests, which reports the results to a database for tracking the
performance.  That way, you'll be able to pin-point regressions over
time.  These Beaker tests may take many hours to run.  But with the
tracking, you'll get a good overview over what fails and what works, and
how well it works.

Even though it should be a restricted access to the job scheduler for
the tests, the reports from it should be available to the community.
This way developers in the community can follow how the testing is done
and give feedback if something is wrong with the tests or OpenVPN.  In
addition, if the test scripts are available for the community, it can
help out improving and providing new test scripts.  With such an open
approach, the community will also be involved in the QA work.


But I do realise, such a setup is not too easy to acquire.  It requires
hardware, and a lot of work to come this far.  But I do believe this is
one (of many) reasonable ways to automate tests and to make sure OpenVPN
will continue to stay as a stable product.  And in the long run, it
might help reducing the workload key-persons in the OpenVPN team may have.


That's probably enough thoughts for today :)


kind regards,

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

iEYEARECAAYFAkskB8sACgkQDC186MBRfrq7QgCfaTLJ8gyT2f4AY0CibA3Ddhyx
9oAAnRPrqXWEMTpNQeHAd9jwrPXgm1By
=IZ3w
-----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 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

[@ 2009-12-14 12:52 UTC (permalink / raw)]

David Sommerseth ha scritto:
> On 12/12/09 12:37, Samuli Seppänen wrote:
> > Now, if we want to maintain stability, we need some way to test the
> > patches. Automated tests could be used in many cases but building the
> > test cases takes time. In addition I don't think automated tests catch
> > nearly all problems, so manual testing is required. I'm not a specialist
> > in VCS systems but I guess a distributed VCS could help in this. What
> > are your thoughts on the testing procedures/tools? Fedora's Beaker suite
> > was mentioned earlier and it sounds interesting.
>
> Let's first give a little introduction of Beaker, so that nobody
> believes it is something exceptionally which solves all the problems.
>
> First of all Beaker is being built up now, it is quite a big project
> consisting of a lot of modules which will communicate together.  I'm not
> sure how far things are in the overall project, but I'll give a little
> intro here about the concept.  Otherwise, beware that crucial modules of
> Beaker might not be ready yet.
>
> A Beaker installation is a big installation.  It is aimed at
> automatically testing software on a broad variety of distributions and
> provide a report of how that test ran.  And you will most probably need
> quite some hardware to get this up and running.
>
> First, Beaker have an inventory module.  Here hosts are registered into
> a database with information about hardware and supported OS and
> distributions.  Then there is a scheduler, which receives requests for
> running particular tests (aka jobs).  The job scheduler then uses the
> inventory to pick out the best suited boxes which are available to run
> the test(s) on.  The inventory is then instructed by the job scheduler
> to do a scratch installation of an assigned OS/distribution.  As a part
> of this OS installation, it will install the defined test scripts on the
> box, run all the tests, collect the results and release the box back to
> the inventory again.
>
> I know the inventory part is pretty much up'n'running, and I believe the
> job scheduler is getting more and more ready.  (It's a while since I
> checked that status) ... so this needs to be checked out.  But as you
> see, some hardware is needed, even though I believe Beaker do (or at
> least will in the future) support virtual hosts as well.  Then the test
> script given to the job scheduler will define who each of the virtual
> hosts will be installed as well.
>
> The good thing about the Beaker framework is that you usually just need
> to install a few packages on your own local box to develop and run the
> test scripts locally.  When the script is ready, it's packaged and sent
> to the tests repository in Beaker.  So it is also possible to run Beaker
> in a very small scale for test development.
>
> You can also browse the test repository via web, and ask for certain
> tests to be run.  The test script defines which packages is needed to
> run the test, and the software being tested needs to be put into a
> special repository, where the script will download and install the
> package, as a part of the test run.
>
> There's also features like multi-host tests, where more hosts are
> involved to run one single test, to test communication between hosts,
> etc.  So this is the direction Beaker is headed.
>
>
> So, back to the topic ... some of these things might already have been
> thought of by the QA team and might even be implemented.  But as I don't
> know how the OpenVPN team does the QA work, I'll share my thoughts here
> ... how I see the "perfect" world :)
>
> Anyhow, you can use such an infrastructure as Beaker to test patches, as
> you vaguely indicated, Samuli.  But Beaker is usually much more suitable
> for testing an already compiled and packaged piece of software before
> shipment.  But of course, it's all scripts, and it can also download
> source code and compile it too.  But I'm not sure how well it will
> perform under these conditions, it might be better with another approach.
>
> However, I would recommend a setup which only a few of the developers
> James will cooperate closely with, including James, will have access to.
>  This setup will do a build of the source code at a given commit, and
> run a standard test suite, aimed at the first stage of the development
> cycle.  This should test for compilation issues (including warnings) and
> report them to the developers.  It should run openvpn in a few different
> modes, with different options to test generic functionality.  It might
> support different test modes, so that the test script will take between
> 5 minutes and 30 minutes, it might even be a few different tests with
> different run times.  This is only aimed at giving a quick indication on
> how well the code is running.
>
> Then when much more commits have been collected, a preliminary package
> can be compiled and sent to a Beaker setup.  The tests here can be much
> more comprehensive, and ideally should test all options and
> configuration modes of OpenVPN.  One test should also be a performance
> tests, which reports the results to a database for tracking the
> performance.  That way, you'll be able to pin-point regressions over
> time.  These Beaker tests may take many hours to run.  But with the
> tracking, you'll get a good overview over what fails and what works, and
> how well it works.
>
> Even though it should be a restricted access to the job scheduler for
> the tests, the reports from it should be available to the community.
> This way developers in the community can follow how the testing is done
> and give feedback if something is wrong with the tests or OpenVPN.  In
> addition, if the test scripts are available for the community, it can
> help out improving and providing new test scripts.  With such an open
> approach, the community will also be involved in the QA work.
>
>
> But I do realise, such a setup is not too easy to acquire.  It requires
> hardware, and a lot of work to come this far.  But I do believe this is
> one (of many) reasonable ways to automate tests and to make sure OpenVPN
> will continue to stay as a stable product.  And in the long run, it
> might help reducing the workload key-persons in the OpenVPN team may have.
>
>
> That's probably enough thoughts for today :)
>
>
> kind regards,
>
> David Sommerseth
I can't see any reason why the test scripts should be secret. So better
have them in the open. Do you think it'd be possible to have a
distributed network of hosts in the inventory? I'm sure there are tons
of people with extra server resources who could contribute by providing
test hosts. Or is the technology dependent on hosts being in the same
physical LAN? If not, we could use, say, IPSec to connect the boxes
safely together (just kidding :)... OpenVPN makes more sense in our
context).

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

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

[@ 2009-12-14 12:57 UTC (permalink / raw)]

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" ...
> <http://progit.org/book/>.  A video of Linus explaining his thoughts
> behind git, can be viewed here:
> <http://www.youtube.com/watch?v=4XpnKHJAok8>
>
>
> 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

[David Sommerseth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/12/09 13:52, Samuli Seppänen wrote:
> I can't see any reason why the test scripts should be secret. So better
> have them in the open. 

I completely agree!  That's the very best approach!

> Do you think it'd be possible to have a
> distributed network of hosts in the inventory? I'm sure there are tons
> of people with extra server resources who could contribute by providing
> test hosts. Or is the technology dependent on hosts being in the same
> physical LAN? If not, we could use, say, IPSec to connect the boxes
> safely together (just kidding :)... OpenVPN makes more sense in our
> context).

That's a very good question, actually :)  I don't believe it's needed
for these boxes to be on the same network at all.  But it will be some
communication between the scheduler, inventory and the test boxes.
Each local site might need to have a local inventory, I'm not sure how
that really works.

Anyway it must exist some kind of serial port console which is
accessible over the network somehow as well.  But I believe the IPMI SOL
access can be used in most cases, for the hardware which supports that
... Remember that the box is scratch installed on each test run, to
provide a predictable testing environment.


kind regards,

David Sommerseth

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

iEYEARECAAYFAksmN+QACgkQDC186MBRfrqbuQCgrS0L2vRxvjW/sEASuB7d1ak4
Pw4AoJAghuewPSgI5UIUzsTmANzUnonT
=/EGN
-----END PGP SIGNATURE-----