11:34 <@mattock> I just updated a document outlining some aspects of the new development model: it's goals, how to achieve them and what is required for it all to work. It's available here: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html
11:34 < vpnHelper> Title: OpenVPN development (at users.utu.fi)
11:35 <@mattock> now I'll relax for a while before the meeting, see you then :)
11:42 -!- dazo changed the topic of ##openvpn-discussion to: Developer Forum TODAY 1900UTC || Meeting outline: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html || Logs at http://secure-computing.net/logs/%23%23openvpn-discussion.log (updated every 10 mins)
11:56 -!- Kaspx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:56 -!- mode/##openvpn-discussion [+v Kaspx] by ChanServ
11:59 -!- notneb_ [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
11:59 -!- mode/##openvpn-discussion [+v notneb_] by ChanServ
12:02 < ecrist> Applicable todays meeting: http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
12:02 < vpnHelper> Title: Bazaar vs CVS vs Git vs Mercurial vs Subversion Version control systems comparison (at versioncontrolblog.com)
12:04 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 60 (Operation timed out)]
12:07 < reiffert> I think trac will bind us to svn.
12:10  * ecrist is a fan with sticking with svn, anyhow.
12:14 < dazo> http://whygitisbetterthanx.com/
12:14 < vpnHelper> Title: Why Git is Better Than X (at whygitisbetterthanx.com)
12:15 -!- Kasx [n=Kasx@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit [Read error: 110 (Connection timed out)]
12:16 < ecrist> dazo, to be noted, that article is written by someone who works for github
12:16 < dazo> true ... but the fact is that is that it's quite neutral despite that, IMHO
12:17 < dazo> all facts there is possible to verify
12:17 < ecrist> I found it one-sided in some areas.
12:18 < rob0> Emacs!!
12:18 < ecrist> for example, under the 'distributed' heading, he highlights Git with 1m 59s, although SVN is at 1m 4s
12:18 < Bushmills> svn repositiories need somebody well versed with svn, or it gets messy.
12:19 < Bushmills> but i suppose the same could be true for git
12:19 < dazo> the versioncontrolblog.com comparison is very CVS centric ... and compares things which is not really that relevant to what is not too much relevant in regards to development tasks in general
12:19 < ecrist> and he refers to a 53% difference as 'marginal'
12:20 < dazo> yeah, that section has changed since last time I went through this .... that's really odd, I'll give you that one!
12:21 < rob0> Emacs makes it easy, listen, all you have to do is ^X ^M ^I ^C ^K ^E ^Y and then ^X ^M ^O ^U ^S ^E. Spend a few years in the info pages, you'll be as good as Stallman.
12:21 < dazo> git can be messy if you don't know what you do ... indeed, but you only mess up your local copy ....
12:22 < ecrist> I've spent the past 5 hours looking at VCSs and feel like a change isn't needed until a change is needed.
12:22 < dazo> svn is centralised, so if one person screws up .... it's screwed up for everyone
12:22 < ecrist> it can always be reverted
12:23 < dazo> ecrist:  agreed ... but if you want to introduce a better development model, with more reviewers, it gives a lot less pain doing it in a good distributed model than a centralised one
12:23 < dazo> ecrist:  in regards to reverts, yes, if you know how to do it .... but that counts for most vcs's
12:24 < dazo> reiffert:  and trac+git is working very well
12:28 < dazo> for those who want a comparison .... "svn co http://svn.apache.org/repos/asf/qpid/trunk"  and "git clone git://git.apache.org/qpid.git qpid"  .... then poke around the code, modify, try to do commands like {svn,git} {log,diff,status}
12:30 < dazo> svn also claims that branching is cheap .... only costing the resources file copies takes ... fine enough, but how much time do you spend merging it afterwards?  and git branch is the matter of fact writing about 40 bytes to a file
12:32 < dazo> (ftr ... git clone of qpid took 2m55s on my computer .... svn checkout which I started before git, is still running)
12:34 < reiffert> dazo: are you absolutly _sure_?
12:34 < reiffert> dazo: show me one project running trac on git please.
12:34 < dazo> http://projects.autonomy.net.au/python-dmidecode/
12:34 < vpnHelper> Title: Python-DM (at projects.autonomy.net.au)
12:35 < ecrist> doesn't seem to be working well...
12:35 < ribasushi> also don't forget that a git repo pretty much needs a merge-king
12:35 < dazo> funny ... I see the maintainer have some issues now :-P ... not sure what that could be
12:35 < ribasushi> otherwise things get messy even faster
12:35 < ribasushi> with svn you have a single point of truth
12:35 < ribasushi> look at linus - he pretty much has a full time job pulling this and pulling that
12:35 < dazo> ribasushi:  but merging is something I can do 20 times a day if I need to ... it's so fast I don't even consider it a bad thing
12:35 < ecrist> if asked, at this point, my vote would be to stick with svn
12:36 < ribasushi> dazo: merging is fast in any vcs
12:36 < dazo> ribasushi:  that is not true
12:36 < ribasushi> dazo: it's the brainpower that goes into a merge that counts
12:36 -!- theDoc [n=hex@unaffiliated/thedoc] has quit [Read error: 60 (Operation timed out)]
12:36 < ribasushi> dazo: that's fanboi-ism now
12:37 < ribasushi> in fact git encouraging branching (which comes with additional merging) is one of the downsides for me
12:37 < ribasushi> as it taxes the "janitor on duty" with unneeded upkeep
12:38 < dazo> why is branching a bad thing?
12:38 < dazo> ribasushi:  http://www.youtube.com/watch?v=4XpnKHJAok8
12:38 < vpnHelper> Title: YouTube - Tech Talk: Linus Torvalds on git (at www.youtube.com)
12:38 < ribasushi> dazo: I explained everything, stop throwing links at people and think about the arguments for a second
12:39 < dazo> ribasushi:  I do ... I'm using resources as parts of my arguments, instead of saying exactly the same myself ... and I'd like to hear why branching is a bad thing?
12:39 < ribasushi> you want to make it easy for the contributors, but you also don't want to create hell for the maintainer
12:40 < dazo> http://techblog.floorplanner.com/2008/12/09/git-vs-svn-for-bosses/
12:40 < vpnHelper> Title: Git vs SVN for bosses | Floorplanner Tech Blog (at techblog.floorplanner.com)
12:40 < ecrist> I would still say that there's no need for a change until there is a need for a change.
12:40 < dazo> ribasushi:  come on .... do you think the linux kernel would be able to handle about 1000 patches a day if that was a bad approach?
12:41 < ribasushi> all of the "branching sucks in svn" is a <= 1.5 mantra
12:41 < ribasushi> ecrist++
12:41 < ecrist> The first question that needs to be asked/answered, is what isn't SVN doing that OpenVPN needs it to do.
12:41 < ribasushi> ecrist: 1) doesn't appease fanbois :)
12:42 < ecrist> if there is nothing in that list other than on potential contributor prefers git, a change does not make sense.
12:44 < dazo> ecrist:  first of all ... with svn you will need to have a commit policy, some people need to have commit access.  With git, all that goes away.  The main maintainer has his circle of people where he knows where he can get good code.  He pulls those trees, merges and publishes his changes as the official tree .... several trees can exist in parallel, where different approaches are tried out on the outside of the main repository, an
12:44 < dazo> d what is good will easily be merged into the main tree when the code is ready for it
12:44 < dazo> that is a working model which centralised solutions is not good at
12:45 < dazo> you need to have branches, commit access is defined on all branches in SVN
12:45 < dazo> svn is not as flexible, it is that easy
12:45 < ecrist> dazo: commit access can be garnered with simple .htaccess files with DAV/SVN
12:46 < ecrist> it sounds like you're creating a problem where an actual problem has yet to be presented.
12:46 < ecrist> the infamous, 'what if'
12:47 < rob0> And I resent that, because that's MY role, to create problems!
12:47 < ecrist> lol
12:48 <@mattock> does everybody agree that if there are real problems with SVN then we should consider Git?
12:48 <@mattock> or some other distributed VCS
12:48 < ribasushi> mattock: we don't agree on "real"
12:48 < ribasushi> the rest is an obvious question :)
12:49 <@mattock> ribasushi: bad choicing of words... "if there will be"
12:49 <@mattock> or "if we encounter"
12:49 < ecrist> mattock: as I've already said, there's no need for a change until there's a need for a change.
12:49 < ecrist> if SVN is working, all it does to change is create more work.
12:49 <@mattock> ecrist: agreed
12:50 <@mattock> problems will find us, if they exist
12:50 < ecrist> only change once SVN doesn't do something that's needed.
12:50 < dazo> but no one seems to be interested in looking into what git saves compared against svn
12:51 -!- derRichard [n=derRicha@ununbium.nod.at] has joined ##openvpn-discussion
12:51 < dazo> for example not needing to have a svn server running .... a pure http server is enough
12:51 < dazo> which is less maintainance
12:51 < ecrist> dazo, you're only suggesting git because you like it.  I'm sure it does some things better, but if those features aren't needed, and won't be used, there's a net loss involved in changing.
12:52 < ecrist> dazo: where I work we use SVN, we have no svn process running, only apache with mod_dav
12:52 < ecrist> you don't need to use the daemon binary to use svn
12:53 < dazo> I have experience with git, svn, tla (similar to bzr) and cvs ... and I've used mercurival in one project .... and I'm advocating git, because that's most known ... but I'd put mercurval as number 2, bzr as 3 and svn as 4 ...
12:53 < dazo> ecrist:  and you don't even need mod_dav with git
12:53 < ecrist> who cares?
12:54 < ecrist> this conversation is moot until a notable lack of feature or function is apparent in svn
12:54 < dazo> inside an organisation, centralised vcs can work exceptionally well ... I have no problems understanding that ... but in the moment you start working with a community, that slows down
12:55 < dazo> speed is obviously not a feature
12:56 <@mattock> I don't personally like using or maintaining SVN, so I'd prefer something else (e.g. Git). But I agree with ecrist that we should check if SVN works well enough first.
12:56 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has joined ##openvpn-discussion
12:56 < dazo> there are even stories about organisations which uses git-svn to pull down svn repos, do the merging in git and push it back to svn ... because svn is much harder with such tasks, which really should be easy
12:57 <@mattock> but move to Git if it solves real problems
12:57 < dazo> I follow that one
12:57 <@mattock> but we don't really know the development model yet, so
12:57 < rob0> James is not here yet. When he gets here we can tell him what we've decided, and adjourn!
12:58  * ecrist is but a peon and doesn't make decisions.
12:59 <@mattock> rob0, sounds like a plan :)
12:59 <@mattock> rob0: what was our decision again? :)
12:59 <@mattock> to move to Git?
13:00 -!- jamesyonan [n=jamesyon@c-76-120-71-74.hsd1.co.comcast.net] has joined ##openvpn-discussion
13:00 < jamesyonan> hi
13:00 <@mattock> hi james
13:01 <+Kaspx> Hey Guys!
13:01 <@mattock> jamesyonan, I created a plan on what _I_ think we (the company) are trying to achieve with the development model change and how. Could you take a look: http://users.utu.fi/sjsepp/openvpn/openvpn_development_requirements.mm.html
13:01 < vpnHelper> Title: OpenVPN development (at users.utu.fi)
13:04 <@mattock> I hope we manage to find an agreement how to improve the OpenVPN development model so that, in the long run, everybody (company and community) as well as the application benefits
13:05 < dazo> what about to set some expectations first?  if you guys (openvpn ppl) could put words on what you would like to gain from the community, and how the community could gain from you
13:06 < dazo> in your point of view
13:06 <@mattock> dazo, some of that is outlined in the document I linked to
13:06 <@mattock> most of it should benefit the community, too
13:06 < dazo> yeah, I'm just trying to formulate it as a question
13:07 < dazo> but *what* should benefit for the community ... in your POV
13:07 < ecrist> perhaps, 'Why are you here.' works?
13:07 < dazo> yeah :)
13:07 <@mattock> ecrist: well put
13:07 < jamesyonan> Agreed.  I think the important thing is to find a model that is both open, but also protects the integrity of the code, given that so many people rely on OpenVPN as being a mature, stable project
13:08 < ecrist> I've tried to get OpenVPN staff involved in the community for nearly two years, and only been met with hostility.  This is a sudden change.  I'm curious as to why the change, and what are you looking to gain from the community.
13:08 <@mattock> I guess James is the best person to answer that one
13:08 <@mattock> I haven't been onboard that long
13:09 < jamesyonan> Well I think it's a problem that has beset other open source projects.  The founder becomes the bottleneck.
13:09 < ecrist> I've never dealt with James that I recall, only Francis Dinha.
13:09 < reiffert> Seen this on macports as well.
13:09 <@mattock> this is my impression of the main problem
13:09 < reiffert> Kepts progress off nearly 2 years.
13:11 < dazo> so, it is some expectations that the community will help out bringing openvpn further, more rapidly but maintaining the code quality?
13:11 <@mattock> ecrist: I don't believe there's ever been intended hostility from the company's part.
13:11 < jamesyonan> Certainly I've never intended to be hostile.
13:12 <@mattock> dazo: more rapidly, yes, and without OpenVPN falling apart
13:12 <@mattock> I'd like to your thoughts about all this... what benefits would a more open model give you (the community)?
13:12 < dazo> mattock:  falling apart ... like loosing quality?  Hurting the OpenVPN company?  forks?
13:13 <@mattock> dazo: I mean code quality and such
13:13 -!- frankbob [n=frankbob@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
13:13 -!- mode/##openvpn-discussion [+v frankbob] by ChanServ
13:13 < dazo> oki
13:14 < jamesyonan> But I've had to balance a lot of competing priorities.  A lot of what I've been involved with during the last two years is bringing up OpenVPN Tech to the point where we have the resources to properly manage OpenVPN as a community project without myself being the bottleneck.
13:14 < dazo> jamesyonan:  how can then a community help you out?  in your eyes
13:15 < jamesyonan> A few things... Certainly testing beta releases is a critical role.
13:16 < reiffert> :)
13:16 < rob0> Well, I ran 2.1 betas a long time, but never had a problem to report :)
13:16 < jamesyonan> Contributing to the development is important as well, with several caveats.
13:16 < dazo> :)
13:17 < fkr> which caveats?
13:17 < fkr> (good evening,  btw)
13:18 -!- nneul [n=nneul@infinity.srv.mst.edu] has joined ##openvpn-discussion
13:18 < jamesyonan> I think the major caveat is that with a project of OpenVPN's maturity, code quality becomes critical, especially with respect to security.
13:19  * ecrist agrees
13:19 < fkr> of course, it is.
13:19 < jamesyonan> I've had people submit patches to me that contained security vulnerabilities.
13:20 < dazo> which means that you need people helping out reviewing new code, which follows certain coding standards
13:20 < fkr> thats why becoming part of an active development group is always a process that takes it's time (from my perspective)
13:20 < dazo> +1
13:21 <@mattock> I think having more people working on the code will in the long run increase code quality... of course at first there'll be problems, but if the problems are communicated and fixed, things start to change
13:21 <@mattock> I mean problems with the code
13:21 < reiffert> jamesyonan: having an unstable tree helps getting from a first approximation towards a stable and secure solution.
13:22 < fkr> ugh
13:22 <@mattock> agreed
13:22 < fkr> unstable, insecure code will not turn stable and secure. I highly doubt that. if crap hits a source tree, it is hard to get rid off
13:23 < dazo> yes, unless people reviewing code have knowledge to catch such issues during the review process
13:23 -!- mintaka [n=kosmic@unaffiliated/spice] has joined ##openvpn-discussion
13:23 < reiffert> ack
13:24 < dazo> jamesyonan:  are there any defined coding rules which you follow for the development of openvpn which would help out people reviewing the code?
13:24 <@mattock> a code preview (static whitebox testing if you will) should catch some problems off the bat... the rest will show up later during live testing (or in regression tests, if any)
13:24 < dazo> jamesyonan:  another question ... how often do you receive patches from users?
13:24 < jamesyonan> can we look to other security projects to gain insight on best policies?  For example, how does OpenSSL manage patch submission?
13:25 <@mattock> jamesyonan, I think that's worth checking
13:25 < dazo> yes
13:25 < ecrist> most projects I've worked with have patches submitted via the ticket system
13:26 < ecrist> they are reviewed and either declined or accepted into the tree with changes.
13:26 < fkr> bugzilla and tech@openbsd.org (for OpenSSH)
13:26 < ecrist> some changes are made by the reviewer, others are required to be made by the submitter before further review
13:27 <@mattock> in any case, I guess we want to, a) increase the quality of the code that is contributed, b) detect problems as soon as possible, c) communicate the problems (to increase the quality of the code)
13:27 < dazo> patches goes into a ticketting system or a mailing list, would be really beneficial
13:27 <@mattock> a ticketing system definitely helps... at least problems (and fixes) are not lost in space and time (like in the mailinglists)
13:28 < derRichard> i think a public (and maintained!) bug tracker is most important
13:28 -!- Olrick [n=Olrick@unaffiliated/olrick] has joined ##openvpn-discussion
13:29 < dazo> actually a bug tracker and patch tracking goes hand in hand
13:29 <@mattock> jamesyonan, would it help if others could preview (and pre-approve) the patches before they get to you? To save some of your resources... for example, communicate any obvious problems to the author
13:30 < reiffert> Why should everything still run through the bottleneck?
13:31 <@mattock> reiffert: good question?
13:31 <@mattock> oops, remove the question mark :)
13:32 < jamesyonan> Yes, that would make sense -- I think the basic questions to ask about a new submission are: (a) is the code quality up-to-par, and (b) is this something important to enough people that it's justified to merge into the mainline
13:32 < ecrist> the community, I think, would be a good 'firewall' on a ticket systems
13:32 < ecrist> s/s$//
13:33 <@mattock> ecrist: could you elaborate?
13:33 < reiffert> ecrist: the user community like we are, or a possible development community, like .. ?
13:34 < ecrist> I would say the current community (IRC/Forum) with rights within the ticket system to elevate
13:34 < ecrist> OpenVPN Tech could ignore anything below a certain level, or within a certain category.
13:35 <@mattock> ecrist: sounds good
13:35 < ecrist> the community mods would promote a vetted ticket to an area OpenVPN Tech would notice
13:35 < dazo> jamesyonan:  the Linux kernel tree operates with different source trees, where each tree has a focus area with its own sub-tree maintainer .... would such an approach be valuable here?  Where you could take already tested and code which has gone through a first "review filter"
13:35 < reiffert> Never mind, IRC/Forum is still a user community with no coding skills.
13:35 < fkr> reiffert: ack
13:36 < ecrist> reiffert: most tickets coming in to a ticket system are user-level.
13:36 < ecrist> no matter the title of the ticket system
13:36 < ecrist> "SUPER DUPER DEVELOPER ONLY TICKET SYSTEM"  -> Ticket 1: How do I install openvpn on Windows?
13:37 < reiffert> follow the guide, wontfix.
13:37 < dazo> ecrist:  the failure here ... you use the words "SUPER DUPER" ;-)
13:37 <+Kaspx> haha
13:37 < jamesyonan> Yes, I think having different source trees makes sense.  I would like to see feature-addition patches actually used in an experimental branch and vouched for as being stable and useful by multiple users before they are considered to be merged into the trunk.
13:38 <@mattock> jamesyonan, I agree... I originally envisioned separate feature testing trees to speed up inclusion of new features... in the linux kernel style as dazo suggested. I'm not sure if that makes sense, but it's one possibility
13:40 <@mattock> jamesyonan, how does code end up in the "stable" branch currently? Do we have an experimental/unstable branch?
13:40 < reiffert> Where are all the billion of kernel coders that actually invent progress? It will end up in having 24 experimentell branches, no feedback and still no progress.
13:41 < jamesyonan> Leading up to 2.1, we had a "BETA21" branch where all the development was occurring.
13:41 < dazo> another issue here, is to have some good ways of getting feedback back from users of new features ... so that it can be documented that a particular feature is used and needed
13:41 < jamesyonan> That has since been promoted to 2.1 final.
13:41 < reiffert> jamesyonan: lemme recall how long it took getting from 2.0 stable to 2.1..
13:42 <@mattock> reiffert: that's definitely a problem if people are not using the experimental branches and/or not providing feedback
13:42 < reiffert> or .. how many fixed have there been, fixing two lines of code, coming right one day after the last release?
13:42 < jamesyonan> Well if you look at the change log, there were hundreds of bugs that were fixed.
13:42 < reiffert> s,fixed,fixes,
13:42 < dazo> I also think one problem in this period was that the community knew nothing about why it took so long time .... what the issues were which kept stalling it
13:43 < jamesyonan> The problem with bug fixes is that there's a long latency.
13:43 < jamesyonan> You put a fix out there, and if it breaks something, you might not hear about it for weeks.
13:44 < dazo> how can this be solved more efficiently?
13:44 <@mattock> jamesyonan, wouldn't it help if we had daily snapshots in a repository (e.g. Debian experimental)?
13:44 <@mattock> I guess it's too big hassle to always keep the OpenVPN installation updated
13:45 <@mattock> so few people do it, even if they are motivated to help the project
13:45 < dazo> mattock:  Not sure how quick you would get changes into repos .... for Fedora, that takes 2-3 days at best .... Debian has a similar thing with their repos
13:45 < reiffert> releasing stable versions will put them into linux distros, reaching tons of users...
13:45 <@mattock> dazo: we could have our own repo... for those who want to help. And I'm sure there are a few of those, if given the means
13:46 < dazo> I believe most people who want to do such help are able to grab the source code and compile it .... but nightly tarballs can make it easier for some
13:46 < ecrist> sorry, stepped away
13:48 < ecrist> building a freebsd package is easy enough
13:48 <@mattock> dazo: it's not so much if they can, but if they will... a longer process (svn co;./configure;make;make install...) is worse than a shorter process (automated Debian install)
13:48 < jamesyonan> The latency between fixing bugs and getting feedback on a new beta release is really key to accelerating the release process
13:48 < cron2> I think part of that is having focussed betas with shorter cycles.  As in "only 3 things have changed here"
13:48 < dazo> but I think then one of the issues here is that the community don't know which bugs you need to fix ...
13:48 <@mattock> so we need to get new code to run on people's computer as soon as possible
13:48 < ecrist> jamesyonan: given some communication paths, we would likely be successful pushing beta testing in IRC and on the forums
13:49 < cron2> has "automated testing" been discussed already?  (I've just joined, and not read up on the backlog)
13:49 < dazo> cron2:  nope, not yet
13:49 <@mattock> cron2: frequent releases are a good idea... most people won't install "non-stable" software, even if it is rock solid. Or that's my experience
13:49  * cron2 claims "automated testing would help"
13:50 <@mattock> cron2: agreed
13:50 < dazo> mattock:  exactly .... because
13:50 < reiffert> mhm, finding missing libraries, but what else?
13:50 < dazo> nobody want's to compromise VPN security
13:50 < jamesyonan> automated testing would be great, but how much effort would it take to develop it?
13:51 <@mattock> reiffert: regression tests come to mind
13:51 < derRichard> jamesyonan: we could use usermodelinux like strongswan does.
13:51 < cron2> it really depends on the extent you want to go
13:51 < dazo> jamesyonan:  automated testing is not difficult itself ... what is more difficult is to have defined what needs to be tested and how
13:51 < jamesyonan> Re: automated testing, one resource we already have is Coverity's compile-time checker
13:51 < cron2> there's "make check" style testing, running locally on a given platform (which is already there to some extent)
13:51 < cron2> and then there's "build farm testing", fanning out source to 20 different operating systems, all running interop tests - now *that* is tough...
13:51 < dazo> and Fedora's build does even more during build
13:52 < nneul> joining in late - is there some clear information on what the plan is as far as existing developers? i.e. is the community development effort going to be completely separate, or overlapping developers with the commercial product?
13:52 <@mattock> I think quite a few aspects of OpenVPN's operation could have automated (regression) tests, but building them takes time... and if we have tons of automated tests, they break when significant changes are made to how the application functions -> tests need fixing
13:53 < dazo> But such testing could maybe even be done in cooperation with f.ex Linux distributors as well .... Fedora/RHEL have their infrastructure, I bet Debian, Novell/openSuSE, Gentoo, etc also have similar setups
13:53 < nneul> current issue is that there doesn't appear to be any clear way to get information to/from active developers who know the internal details of the product - I was trying to submit an improvement, but no way to do it reasonably without getting some more information from someone who is familiar with the detailed internal implementation
13:53 < cron2> mattock: yes, it needs some effort.  But then you can do more dramatic code changes with the good feeling "if the tests all still work, I have not broken anything user-visible"
13:54 <@mattock> do we all agree that new code needs to get "out there" a.s.a.p.?
13:54 < cron2> +1
13:55 <@mattock> cron2: true
13:55 < jamesyonan> I've found from experience, that more people will test the release if the release cycles are less frequent
13:55 < dazo> I feel we are starting a bit skewed out now .... because we want code out .... but which code?  the community knows *nothing* about the further plans for OpenVPN, the direction jamesyonan would like to see openvpn go
13:55 < jamesyonan> that's just a caveat against what generally seems like a good idea, i.e. to release early and often
13:56 < dazo> we are missing info about which bugs that exists, which issues are being solved .... and which issues are on the task list
13:56 < cron2> jamesyonan: yes, that's true for manual testing - people lose interest if they have to test once a week.  OTOH, if the incremental changes are smaller, we might not need so many testers per release
13:56 < dazo> just by being more open here, you can also get more people helping out writing that code
13:56 < cron2> dazo: ack
13:57 <@mattock> cron2: I agree we don't need as many testers when there are only a few changes
13:57 < jamesyonan> I see OpenVPN 2.1 as being mature code that's suitable for incremental improvements.
13:58 < jamesyonan> I have some ideas for OpenVPN 3 that would involve redeveloping OpenVPN as a general purpose user-space network stack
13:59 < cron2> I agree with 2.1 being a good platform to go ahead
13:59 < derRichard> jamesyonan: btw: are there any plans to develop a openvpn client for smartphones? (iphone and such crap..)
14:00 < dazo> derRichard:  that's where the community comes in ;-)
14:00 < jamesyonan> yes, certainly the community can take the initiative on this
14:00 < derRichard> i don't think so.
14:00 <@mattock> derRichard: why is that?
14:00 < jamesyonan> OpenVPN Tech is also developing a new client for the Access Server and at some point when the code matures a bit, we plan to open source it
14:01 < derRichard> writing a vpn tool for the iphone is not that easy. a iphone app runs in a jail. we need apple to get access to a real network-device...
14:01 < dazo> jamesyonan:  do you have any reason why not open source it immediately?  And get more people looking at it sooner?
14:01 < jamesyonan> Well the community has ported OpenVPN to other client platforms, such as Windows Mobile
14:01 < derRichard> is this port stable?
14:02 < Schlaubi> some guys asked me for symbian clients
14:02 <@mattock> jamesyonan, why does the AS client have to mature before open sourcing it?
14:02 < derRichard> Schlaubi: that would be great :=)
14:03 < cron2> how are the AS server/client and OpenVPN related?  I thought that this is basically the same thing, with commercial coating or open source?
14:03 < jamesyonan> dazo: right now at OpenVPN Tech our plate is pretty much full.  We don't have the resources yet to put into the extra work that would be required to maintain the AS client as an open source project today.
14:03 < cron2> (so "why a new client?")
14:03  * cron2 is not criticizing anything, just trying to understand
14:04 < dazo> jamesyonan:  this is probably where I fall off ... because if the source is available, and let people test it and contribute code ... sharing a development plan, a roadmap and documentation, I would expect you could get more help getting things done
14:04 < fkr> actually, there are people working on an iphone client, but the tough one is to access routing table and such, which is something that will not be possible on not-jailbroken iPhones (just to sum that up)
14:05 < dazo> without spending more resources on managing it
14:05 < jamesyonan> This is mostly a commercial issue with the Access Server product -- and that's that people want a client that is (a) uniform across all platforms, and (b) has most of the configuration performed on the server side, where there's not so much functionality exposed on the client itself other than connect, disconnect.
14:05 < cron2> I see, thanks
14:06 < jamesyonan> The existing open source OpenVPN clients tend to be more full-featured.  Commercial customers on the other hand don't really want to give a full-featured client to their users.
14:06 < ecrist> jamesyonan: if it hasn't been passed to you yet, http://www.ovpnforum.com/viewforum.php?f=10
14:06 < vpnHelper> Title: OpenVPN Forum View forum - Wishlist (at www.ovpnforum.com)
14:07 < reiffert> how about starting with proper error messages?
14:07 <@mattock> dazo: I agree...  working openly would probably be beneficial with the AS client, too... I think the main issue is how to work openly _and_ effectively
14:08 < dazo> jamesyonan:  I would really applaud splitting the server and the client into to different applications, which I think I understand this as the first step .... as the code should be able to become simpler
14:09 < cron2> dazo: I'm not sure I agree with that.  Large parts of the seriously nasty stuff (system dependent, ifconfig, route, ...) would need to be shared anyway
14:09 < jamesyonan> Originally, OpenVPN was developed for site-to-site rather than client-server, hence the integration of both client and server in the same codebase
14:10  * dazo remember those days :)
14:11 < jamesyonan> To be honest, I think if there's something in OpenVPN that I consider difficult to maintain, it would be the event loop implementation.
14:11 <@mattock> jamesyonan, does OpenVPN have any easy extension point? For things like plugins... I know there are authentication modules and such...
14:12 < dazo> jamesyonan:  amen! ... I get easily lost in that code, I haven't really figured out how things work in there yet
14:12 < dazo> But .... how can we now get further ..... who will do what now for the next steps to follow?  How can the community be involved?
14:12 < jamesyonan> Yes, there are two extension layers:  (a) the management interface, and (b) the plugin model.
14:12 <@mattock> jamesyonan, ok
14:12 < dazo> the frustration which can be found in the community is that we really don't know whats going on .... the main reason there is a community is probably that the source code is avalable
14:13 <@mattock> dazo: so we need to communicate what we (the company) are doing much better, right?
14:13 < jamesyonan> The management interface is fairly well documented.
14:13 -!- notneb_ [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has left ##openvpn-discussion []
14:14 < dazo> mattock:  yes, that would really be a good first step ... with feature plans, milestones, release plans
14:14 <@mattock> in fact, I think good communication is the key...
14:14 < cron2> mattock: the community needs a way to feed input to you, and have some visible recognition
14:14 <@mattock> to successful co-operation
14:14 -!- openvpn2009 [n=email@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has joined ##openvpn-discussion
14:14 -!- mode/##openvpn-discussion [+o openvpn2009] by ChanServ
14:14 <@mattock> cron2: agreed
14:14 < dazo> cron2:  yes!
14:14 < cron2> as in "this is the process to get new code into openvpn" and "that is the process to report and track bugs"
14:15 < dazo> and that those reports and patches are publicly available for everyone
14:15 <@mattock> so we need to have clearly defined (and documented) processes
14:15 < cron2> mattock: yes!
14:15 < dazo> ack!
14:15 <@mattock> and most importantly we need to follow those processes :)
14:15 < dazo> jamesyonan:  are there more people than you doing the development in OpenVPN Tech?
14:16  * dazo gives mattock a bonus point for that comment
14:16 <@mattock> dazo: thanks :)
14:16 <@mattock> jamesyonan, do we have documented processes on "how to contribute" and such?
14:17 < jamesyonan> Yes, we have a few people doing development, though we are still very much a startup with the usual resource issues that startups have.
14:18 <@mattock> I think we should next define and document our development processes
14:18 <@mattock> and start following them
14:18 <@mattock> see how they work, adjusting as necessary
14:20 <@mattock> I also think we agreed that frequent releases and automated tests would be beneficial (code quality, inclusion of new features)... right?
14:20 < cron2> yes
14:21 < jamesyonan> make sense
14:21 <@mattock> and possibly have either an "unstable" tree, or separate "feature under test" trees _if_ people provide enough feedback
14:21 < jamesyonan> makes sense :)
14:22 <@mattock> could we begin the big reformation with these?
14:23 < jamesyonan> agree
14:23 < cron2> +1
14:23 < ecrist> +1
14:23 < dazo> +1 ... but can we set some deadlines on when things are supposed to be "ready"?
14:24 <@mattock> dazo: I can't see any reason why not
14:24 < ecrist> and a path, what's coming first, second, so on?
14:25 < rob0> Who's on first. What's on second.
14:25 <@mattock> ecrist: agreed, a good idea
14:25 -!- Olrick [n=Olrick@unaffiliated/olrick] has left ##openvpn-discussion []
14:25 <@mattock> dazo: what kind of deadlines are you thinking about?
14:25 <@mattock> I mean,when? :)
14:26 <@mattock> I think each of these issues should be discussed on the "devel" mailinglist
14:26 < dazo> well, I'm willing to give OpenVPN Tech the time which you need ... but not too long .... but if the documentation can be done within 8-10 days, that would be a good thing
14:27 <@mattock> dazo: I think I can write a draft of the core processes tomorrow, but I need help with finalizing it
14:27 < dazo> there are some things which might take longer time, and that's fair enough ... but OpenVPN Tech need to communicate some deadlines first
14:27 <@mattock> dazo: some of this is tied to  building of the community site, which might take a while (2 months?)
14:27 < dazo> mattock:  count on me, if you need help .... I can hang out here for those discussions
14:27 <@mattock> dazo: thanks!
14:27 < dazo> mattock:  exactly
14:28 < ecrist> this channel will be persistent
14:28 <@mattock> ecrist: did you set up this channel? If so, thanks!
14:28 <@mattock> wouldn't know what to do without the trusty vpnHelper :)
14:28 < ecrist> np
14:29 < ecrist> another bot, in addition/replacing vpnHelper at some point. vpnHelper does RSS feeds, but not well.
14:29 <@mattock> the automated testing thingy might be tricky, might take some time
14:30 <@mattock> as well the automated package building and repository setup (e.g. daily snapshots for Debian/Fedora/whatever)
14:30 < cron2> this is a long process :)
14:30 <@mattock> cron2: I'm sure we get there eventually :)
14:30 < dazo> mattock:  automated testing would actually be an own meeting, for brainstorming .... but as I said earlier, the core issue here is to first define and document what needs to be tested - automation is done by a script, basically
14:31 <@mattock> dazo: agreed
14:31 <@mattock> do you all think we're soon done for today? I think we now have a plan we can start elaborating
14:31 < reiffert> what do you think of creating a permanent #openvpn-devel channel? Samba runs one too.
14:32 <@mattock> reiffert: I think that'd be a good idea, #openvpn seems to have too many users (and usage-oriented questions)
14:32 <+Kaspx> I think that would be a good idea as well.
14:32 < cron2> reiffert: yes, sounds good
14:32 <@mattock> perhaps it could replace this one?
14:33 < Schlaubi> and a monthly /all 2 month meeting?
14:33 < dazo> that can work out .... if some hard core openvpn developers are also present there regularly
14:33 < reiffert> And I really like this discussion, can't we have one every week?
14:33 < dazo> if not ... it makes not so much sense
14:33 <@mattock> reiffert: I agree, we had weekly meetings in Adito/OpenVPN ALS and they were very useful
14:33 <+Kaspx> reiffert: At this time, I think that would be a great idea.
14:34 <@mattock> jamesyonan, what do you think about a weekly meeting? I think one hour should be enough if the meeting are frequent
14:34 < reiffert> jamesyonan: what are your current plans for the next week, can we expect getting trac on its feets?
14:35 < jamesyonan> Yes, I could do a weekly meeting.
14:36 <@mattock> reiffert: I don't think it'd be wise to just "spit" a Trac instance somewhere :)... I hope you understand, I have sysadmin background :). Also, one week is not that much
14:36 <@mattock> I think 1-2 months is more reasonable
14:36  * dazo agrees
14:36 <+Kaspx> mattock: I agree, this will take some time to do it right
14:36 < reiffert> mattock: I'm a system engineer, thanks.
14:37 <@mattock> reiffert: ok, point taken
14:37 -!- nneul [n=nneul@infinity.srv.mst.edu] has quit ["Leaving"]
14:37 < dazo> Having an open communication first, which states those milestones and deadlines will anyway be a big step forward, compared to where we stand today
14:38 <@mattock> the community site needs to be built fast and alongside these development... currently it's pretty difficult to put anything on our web pages... so I'm drooling for a wiki
14:40 < dazo> mattock:  will we have a discussion during tomorrow then about core processes?  and can we also manage to have a milestone overview, which includes all those things we've been discussing here?
14:41 <@mattock> dazo: yes, let's talk about that tomorrow... and we should outline our current plans and decisions too, and write them down somewhere
14:41 < dazo> mattock:  when can we see those plans?
14:41 -!- frankbob [n=frankbob@adsl-71-140-186-190.dsl.pltn13.pacbell.net] has quit []
14:41  * dazo needs some hard facts :)
14:42 < ecrist> there are currently 3 IRC channels configured: ##openvpn, ##openvpn-discussion, and #openvpn-devel
14:42 <@mattock> dazo: I mean the plans we (here in IRC) have outlined yesterday and tomorrow... hopefully by early next week
14:42 < ecrist> fwiw
14:42 <@mattock> processes tomorrow, though
14:42 < dazo> mattock:  thx!  I can live with that now
14:43 <@mattock> dazo: I see you like to see some action, that's good :)
14:43 <@mattock> talk is not enough, eh ;)
14:43 < dazo> mattock:  I am a firm believer in deadlines and todo lists ;-)
14:44 < dazo> (in that order! :-P)
14:44 < dazo> I need to run now
14:44 <@mattock> one more thing... should we keep the (important) discussions on the devel mailinglist or in the IRC? I think timezones are a problem if we use IRC.
14:45 < fkr> mailinglists
14:45 < fkr> imho
14:45 < cron2> a focused discussion every now and then on IRC is good, but in general I prefer the list - it's easier to schedule
14:45 < fkr> since that allows even weird timezones to participate
14:45  * derRichard votes for mailinglists too
14:45 <@mattock> I agree mailinglists are best
14:45 < dazo> mattock:  mailinglist primarily .... but discussions can take many days then .... but to have supportive irc meetings in addition can help on the progress
14:46 <@mattock> dazo: sounds like a good compromise
14:46  * dazo need to run
14:46 <@mattock> I think it's pretty clear how we'll proceed from here - the work continues tomorrow
14:46 <@mattock> agreed, everyone?
14:46 < dazo> mattock:  catch you tomorrow then!
14:46 < ecrist> I think an IRC presence is ideal backup to mailing lists
14:47 <@mattock> dazo: bye! see you!
14:47 < dazo> mattock:  ack
14:47 < jamesyonan> take care everyone
14:47 <@mattock> bye james!
14:47 -!- jamesyonan [n=jamesyon@c-76-120-71-74.hsd1.co.comcast.net] has left ##openvpn-discussion []
14:49 -!- dazo is now known as dazo_afk
14:50 <@mattock> ecrist: is it possible to "tag" the IRC chatlogs somehow... e.g. "this was the meeting for week 2 in 2010"
14:50 < ecrist> mattock: I can manually do so sometime tonight and make them available
14:50 < ecrist> the logs in their current form is just from my IRC client
14:50 <@mattock> it'd be nice to have each meetings chatlog as a separate file/page
14:50 <@mattock> oh, the old-fashioned way I use, too :)
14:51 <@mattock> thanks guys, it's been great to talk to you! I gotta go now, it getting later (even more so than yesterday)
14:51 <@mattock> bye!
14:52 -!- mattock [n=samuli@dyn55-11.yok.fi] has quit ["Leaving."]
14:58 -!- Irssi: ##openvpn-discussion: Total of 17 nicks [1 ops, 0 halfops, 1 voices, 15 normal]
15:24 -!- Schlaubi [n=daniel@p5B0A151B.dip0.t-ipconnect.de] has quit ["Verlassend"]
15:31 < ribasushi> hm hm
15:31 < ribasushi> so how do I get a response to my bugreport now? :D
15:38 -!- TCW__ [i=mschmitt@booster.qnetp.net] has quit [Remote closed the connection]
15:51 -!- rob0 [n=rob0@tuxaloosa.org] has left ##openvpn-discussion ["bye"]
16:38 < reiffert> ribasushi: 1-2 Months.