Hi, Here's the summary of the previous IRC meeting / sprint.
--- COMMUNITY MEETING Place: #openvpn-devel on irc.freenode.net List-Post: openvpn-devel@lists.sourceforge.net Date: Thursday 26th Apr 2012 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26> Next meeting will be announced in advance, but will probably be on the same weekday and at the same time. Your local meeting time is easy to check from services such as <http://www.timeanddate.com/worldclock> or with $ date -u SUMMARY alonbl, andj, cron2, dazo, ecrist, jamesyonan and mattock participated in this meeting. -- Discussed the "cleanup: windows: convert argv (UCS-2 to UTF-8) at earliest" patch: <https://github.com/alonbl/openvpn/compare/master...unicode> Agreed that this patch makes sense. Alonbl has tested this patch with Hebrew characters on Windows XP and Windows 2008 server. Mattock promised to do further tests on Windows 7. If those go well, the patch will be merged. -- Discussed the "build: rename bool->obool" patch: <https://github.com/alonbl/openvpn/compare/master...bool> Decided that going "stdbool" makes most sense. Alonbl promised to provide a replacement patch. -- Discussed the "crash: packet_id_debug_print: sl may be null" patch: <https://github.com/alonbl/openvpn/compare/master...crash> Jamesyonan gave this patch an ACK. -- Discussed moving the Git repos from SF.net to GitHub: <https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Projectstructure> <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Gitrepos:GitHub-SF.net> <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Gitrepolayout> Made a number of decisions regarding this: - move all Git repos to GitHub - keep the SF.net Git repos in sync with GitHub (as a backup). - do peer review (a.k.a. review patches) using the GitHub web interface - send completed patches to openvpn-devel mailinglist for discussion and (further) review - summarize useful GitHub comments in mailing list posts and/or Git commit messages -- Discussed the "[Focus on] subsystems vs. features" development approach suggested by alonbl: <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Subsystemsvs.features> Did not reach any consensus at this point, but noted the issues this approach is trying to address. Decided to continue the discussion later on the mailing list. -- Discussed the "ACK -> maintenance responsibility?" suggestion from alonbl: <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#ACK-maintenanceresponsibility> Did not reach any consensus, but this approach would probably make sense if we had dedicated subsystem maintainers (see above). Decided to continue the discussion later on the mailing list. -- Discussed the OpenVPN 2.4 release: <https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#OpenVPN2.4> Agreed that focusing 2.4 release cycle to cleaning up, refactoring and modularizing the codebase makes sense and addresses many of concerns pointed out regarding project's long-term viability. This cleanup and simplification work would also help bring in new contributors, i.e. lower the barriers to entry due to simpler and more understandable codebase. Also decided to freeze 2.3 as soon as possible, so that this cleaning up can start for good. -- Discussed the state of buildbot connectivity tests. Mattock promised to install the public test server VM on Friday, and cron2 will then configure it. Once ready, mattock will add test server integration to the buildmaster server. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
ok, topic list here: https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26 vpnHelper 21.05.12 Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) mattock 21.05.17 fairly heavy today shall we start with Alon's remaining patches? 21.05.32 dazo 21.06.52 the first (C++ plugin) was ACKed by Fabian today ... and I agree to it, even though I haven't tested it ... it's standard way to support C++, and makes sense to have mattock 21.07.01 ok, good dazo 21.07.22 C++ comments to C comments ... no-brainer, and ACKed by Fabian cron2 21.07.23 Fabian also acked the master...warnings thing +1 21.07.28 Fabian also acked gitattributes, if I saw that right 21.07.57 dazo 21.08.01 jamesyonan: what's your take on this one ... https://github.com/alonbl/openvpn/compare/master...unicode vpnHelper 21.08.02 Title: Comparing master...unicode · alonbl/openvpn · GitHub (at github.com) dazo 21.08.06 cron2: he did cron2 21.08.26 yep, he did *cannot comment on windows unicode stuff* 21.09.02 dazo 21.09.52 from what I recall d12fk said, it's more a cosmetic thing ... neither approaches are wrong ... it's just two very different ways of solving the same issue jamesyonan 21.10.09 what is better about the new approach? dazo 21.10.18 alonbl: ^^ mattock 21.10.55 alonbl: fyi: I modified this page heavily today: https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem vpnHelper 21.10.56 Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) alonbl 21.10.57 @jamesyonan: the new approach is doing the UCS2->UTF8 conversion at earliest, giving a common bootstrap afterwards. @jamesyonan: it also remving extra dependency in shell32 library. 21.11.18 mattock 21.11.31 alonbl: reducing conditionals further down the road I presume? alonbl 21.12.12 @jamesyonan: the problem is: POSIX gets main() arguments in UTF-8, solution should be how to reach the same state, not to modify the options module in order to re-read command-line from operating system. jamesyonan 21.12.12 does this allow unicode chars to be given on command line when openvpn is run from shell prompt? dazo 21.12.36 (the current approach does, iirc d12fk right) alonbl 21.13.43 @jamesyonan: yes. it uses wmain() in order to get UCS2 arguments, converting it to UTF-8 and call to legacy code. I will be happy if someone else will check this, for me it works great. jamesyonan 21.14.36 has this been tested on a range of different Windows versions? alonbl 21.14.54 @mattock: sure. mattock 21.15.09 if not, I got Windows 7, WinXP and Windowns 2008r2 server at my disposal if somebody can provide a test case 21.15.21 alonbl 21.15.21 @jamesyonan: I tested this on XP and 2008. jamesyonan 21.16.00 do we support win2k any longer? mattock 21.16.03 nope alonbl 21.16.08 @mattock: test case is simple... for me at least... I use Hebrew to test unicode, it tests non-ascii *AND* right-to-left ordering mattock 21.16.11 dropped support @2.1.4 alonbl: oh 21.16.22 I could test ancient greek, if somebody is using that in production 21.16.31 ok, so do we need further testing? 21.17.18 jamesyonan 21.17.57 has it been tested on win 7? dazo 21.18.39 I would generally believe 2008 and 7 is fairly close ... but agree that it should get an explicit Win7 fix jamesyonan 21.18.41 usually if something works on XP and Win 7 it's a good bet it will work on intermediate versions alonbl 21.18.42 @jamesyonan: No, should not be any problem as nothing was changed in win7 in this regard, if someone has access to windows 7 I will be happy to work with. mattock 21.19.06 I can do a quick test on Win7 during this meeting so, I just need to add non-ASCII characters to openvpn arguments and see what happens? 21.19.30 where should I see the breakage (if any)? 21.19.39 dazo 21.20.32 mattock: create a config file with your special Finish chars ... and also have some cert/key files with such chars ... and see how openvpn behaves from the command line and the GUI jamesyonan 21.20.44 if you use "verb 4" openvpn should echo arguments back to stdout mattock 21.20.49 ok, I'll do that next patch? 21.22.15 dazo 21.23.10 the bool -> obool patch mattock 21.23.13 yeah cron2 21.23.15 yeah alonbl 21.23.23 Yes, this one worth a discussion. mattock 21.23.38 alonbl added some info here: https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Patches vpnHelper 21.23.40 Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) cron2 21.23.44 it's good that James is here "we need a decision from above, there is too much religion involved!" mattock 21.24.13 dazo 21.25.09 tbh, I haven't changed my opinion on this one .... I don't like this approach .... even though, some compilers treat bool differently - I don't see the issue if we code wise treat it consequent cron2 21.25.13 *does not particularily like "obool" and would prefer fixing everything that breaks if we move to <stdbool.h> - *but* I'm not trying to insist on anything* jamesyonan 21.25.25 well one of the big problems with global search/replace patches like this (irrespective of the merit of the patch) is that it can create a merge conflict barrier at the patch point dazo 21.26.04 an option I might be willing to consier is to use typedef and not #define macros .... as typedef will be stricter in what you can use the type for jamesyonan 21.26.05 i.e. patches based on stuff before the patch become difficult to merge after the patch point alonbl 21.26.10 @jamesyonan: right, however, the new build already created this situation... so we can push this a bit forther... dazo 21.26.59 well, it's not that hard to apply patches from before these big changes we have included now .... mostly, it's just to apply patches in ./src/openvpn instead of ./ alonbl 21.27.27 @dazo: I agree, I did not want to change anything but the name of the type... can do this as well. @dazo: the platform change and naming were significant. Anyway, I don't think this is the curtial argument here... 21.28.07 dazo 21.28.56 what would happen if we did something like this? (not tested, just thinking aloud) .... #undef bool \n typedef bool { false = 0, true =1 }; \n andj 21.29.10 Could you remind me what's wrong with the stdbool approach? alonbl 21.30.07 @andj: stdbool is gcc specific, it also does not define sizeof(bool), and it conflict with C++ application that #include C code. cron2 21.30.13 andj: when gentoo did that, openvpn stopped working correctly. "bool" was used in some places to carry bitfield *flags* - which got fixed, so it might actually work now we don't use sizeof(bool) anywhere, do we? 21.30.40 alonbl 21.30.49 @dazo: I don't like to play games with the compiler... either we fix this or not... andj 21.30.54 alonbl: isn't stdbool.h C99? dazo 21.31.10 I've done quite some job reviewing bool usage over the whole code base (still got a bit left), but that code path which Gentoo hit is the only place I found issues (where bool was abused as flags) alonbl 21.31.13 @andj: should be, but even then, problem remains. cron2 21.31.50 *doesn't see "the problem", if it doesn't actually break the code anymore due to type abuse* alonbl 21.32.13 @cron2: no, I just outline the issues... for example a struct { bool x; } which is stored to file cannot be read by other code compiled using different compiler. dazo 21.32.17 type abuse are a different type of issues, which should be solved by solving the abuse andj 21.32.22 I'd like to see stdbool.h, as I like standards, even if they're relatively new ('99) cron2 21.32.31 alonbl: since we're not doing that, why should we bother? andj 21.32.35 *needs to go eat quick, brb* cron2 21.32.43 dazo: +1 andj 21.32.48 so you've heard my 2c and agree with dazo there 21.32.59 cron2 21.33.07 if we go for stdbool, I see work for dazo ("finish your review") dazo 21.33.14 *don't mind that* 21.33.17 jamesyonan 21.33.43 I would tend to prefer an alterative that doesn't involve renaming bool alonbl 21.34.19 What happens if someone wish to write plugin in C++ and we have bool in openvpn-plugin.h? cron2 21.34.56 there is no bool in there alonbl 21.35.16 @cron2: currently. jamesyonan 21.35.21 can we conditionalize the C definition of bool only if the compiler is in C mode? alonbl 21.35.51 @jamesyonan: right. the #include will go without errors. I fear about the usage. Anyway, stdbool usage will work... 21.36.35 mattock 21.37.07 +1 one for github: appending .patch to the URL will allow you to download the commit as a patch, nice... jamesyonan 21.37.37 any downside of stdbool? alonbl 21.38.13 @jamesyonan: Major downside (apart of the above) is MSVC, solaris and older gcc does not have this so I need to create emulation anyway at autoconf. cron2 21.38.51 solaris 10 has alonbl 21.39.04 @cron2: which toolchain? cron2 21.39.12 uh sorry, this is opensolaris 10, actually, my solaris10 isn't running right now 21.39.25 jamesyonan 21.39.40 I'm seeing a simple header file that claims to support C99 Boolean types for compilers without C99 support cron2 21.39.42 osol 10 has it right in /usr/include/stdbool.h, without me installing anything dazo 21.39.42 *brb* jamesyonan 21.40.08 http://stackoverflow.com/questions/25461/interfacing-with-stdbool-h-c vpnHelper 21.40.09 Title: interfacing with stdbool.h C++ - Stack Overflow (at stackoverflow.com) andj 21.40.17 stdbool.h itself is very simple alonbl 21.40.30 @andj: right. @cron2: yes, it was added (if I remember correctly) in recent sun studio (12.something) 21.41.14 So I guess we go ahead with stdbool, I will create emulation layer at autoconf and MSVC. 21.41.35 andj 21.41.51 awesome cron2 21.42.18 alonbl: never used sun studio for anything, that's payware - always used gcc on solaris - but indeed, that's a good point alonbl 21.42.59 [... I still fear of using stdbool in my own projects... ] jamesyonan 21.43.40 but doesn't stdbool provide a reasonable compatibility layer with C++ bool? alonbl 21.45.00 @jamesyonan: I had negative experience with C/C++ interaction, especially if using two different compilers... so I prefer to use C as typedef int mybool and not be worry... jamesyonan 21.48.08 yeah but the cost is a giant search-replace patch and diversion from the universally recognizable bool type andj 21.48.37 and moving away from a standrd jamesyonan 21.50.09 +1 for stdbool approach alonbl 21.50.48 @mattock: what about https://github.com/alonbl/openvpn/compare/master...build, https://github.com/alonbl/openvpn/compare/master...crash vpnHelper 21.50.49 Title: Comparing master...crash · alonbl/openvpn · GitHub (at github.com) dazo 21.51.39 those three are already applied this evening alonbl 21.51.42 @jamesyonan: ok, so I will create emulation within build system for system that unsupport this, let's give this a try until the next problem. mattock 21.52.04 dazo: those two? dazo 21.52.20 *see three patches/commits there* build: fix some statement left from conversion, build: properly detect TUNSETPERSIST and build: properly detect netinet/ip.h structs 21.52.33 mattock 21.52.43 ok, ignore me which topic next? 21.53.03 cron2 21.53.10 the master...crash patch I've seen it on the list, and if sl can be NULL there, this patch makes sense 21.53.21 I haven't investigated why it would be NULL, so I haven't commented on it 21.53.32 dazo 21.53.57 I haven't come that far to ACK it yet ... but the fix makes sense alonbl 21.53.58 @cron2: Well, better not to crash first... cron2 21.54.34 alonbl: crashing is not good, but *hiding problems* is not good either - so if it should not be NULL, fix the cause, not the symptom dazo 21.54.56 good popint *point 21.55.15 cron2: this code path is only used if ENABLE_DEBUG is defined ... so this isn't something which is seen much in production 21.56.13 the function where it happens is even packet_id_debug_print() 21.56.36 alonbl 21.57.12 @dazo: yes. cron2 21.57.21 yeah, ok dazo 21.57.39 oh wait ... --disable-debug in ./configure ... so ENABLE_DEBUG is on by default alonbl 21.58.13 @dazo: right. happens to anyone that has verb more than default. cron2 21.58.25 was that default changed? *remembers having used "verb 9" with no crash* 21.58.35 alonbl 21.58.35 @cron2: no. jamesyonan 21.59.20 I think this is reasonable -- other code in packet_id.c takes care to check that this value isn't NULL dazo 21.59.53 *adds an ACKed by james* andj 22.04.00 what's next? mattock 22.04.09 git repo layout? cron2 22.04.11 git repo layout "what goes where" mattock 22.04.20 the topic list is missing some pieces, take a look here: cron2 22.04.21 *defers to dazo "he's da git man"* mattock 22.04.33 https://community.openvpn.net/openvpn/wiki/BuildingUsingGenericBuildsystem#Projectstructure vpnHelper 22.04.36 Title: BuildingUsingGenericBuildsystem – OpenVPN Community (at community.openvpn.net) dazo 22.05.09 when it comes to the openvpn and openvpn-build split ... where openvpn is pure autotools based, makes a lot of sense for me andj 22.05.39 I'm fine any way... cron2 22.05.49 I saw the question more as "where are we going to host these projects" andj 22.05.52 Makes it easier for OpenVPN-NL to use its own build system... cron2 22.05.54 less as "do we want them" andj 22.06.09 "https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#Gitrepos:GitHub-SF.net"; ? 22.06.10 vpnHelper 22.06.10 Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) andj 22.06.11 mattock 22.07.55 yeah, the GitHub vs. SF.net discussion andj 22.08.23 Just to start off: a show of hands, who prefers which system? *<--- github* 22.08.32 mattock 22.08.32 afaik GitHub is superior in many ways to SF.net alonbl 22.08.43 github++ mattock 22.09.04 I'd prefer GitHub myself, too, unless someone can show some downsides (compared to SF.net) alonbl 22.09.32 @mattock: I turly tried to find some... dazo 22.09.34 I'm not comfortable with putting all eggs in one basket ... esp. after the github incident not that long ago, where non-authorised people could get commit access to master mattock 22.09.55 it could potentially increase number of contributions, and also allow more fine-grained access control andj 22.09.56 Isn't the same risk also possible on sf.net? mattock 22.10.09 wasn't SF.net also hacked a while back? alonbl 22.10.11 @dazo: We can always keep some other repository syncked in checkpoints. dazo 22.10.24 which is why I also push out the tree to a server at home and fedorapeople.org alonbl 22.10.24 @mattock: yes. @dazo: so continue doing so. 22.10.41 dazo 22.10.42 yeah, we can easily keep more trees in sync mattock 22.10.58 what about doing development on GitHub and just keeping the SF.net in sync with that? personally, I think it's worth a shot 22.11.10 jamesyonan: do you have any thoughts/opinion on this? 22.11.30 dazo 22.11.43 but I would like all reviews on the ML ... we don't know what happens to github in the future .... and ML are distributed across many systems already alonbl 22.12.07 @dazo: no change in mailing list. andj 22.12.10 dazo: I agree, the ML is more permanent mattock 22.12.47 dazo: you mean finding out "what did people say about this patch"? at some point in the future 22.12.55 dazo 22.13.07 yeah alonbl 22.13.37 dazo: the discussion is to move the git repository, nothing more at this point. Also github does not have mailing list anyway mattock 22.13.37 I was a bit surprised how difficult it was to trace the ACKs given to patches when I did the ACK system review... alonbl: yeah, true 22.13.59 dazo 22.13.59 *considers to modify his git-ack script to also include Message-ID of the patch* mattock 22.14.22 there's nothing mailing list specific at SF.net Git, either dazo: good idea, or some other way of tracing back the discussion 22.14.43 dazo 22.14.54 I'll look at that soonish andj 22.14.57 I'd like to move over to github if only for the friendlier source browser jamesyonan 22.15.01 does github give you the ability to fetch metadata if we we ever wanted to migrate away from the service? alonbl 22.15.05 mattock: we cannot trace back to irc... andj 22.15.18 this is recorded, right? mattock 22.15.22 alonbl: yes, I noticed that also when doing the ACK system review andj: yes, at least in theory, but finding the needle in the haystack may be pretty difficult 22.15.39 L'utente ibins è entrato nella stanza 22:15 alonbl 22.15.54 jamesyonan: git clone has all the metadata... or I fail to understand your question. andj 22.16.08 jamesyonan: what kind of metadata? mattock 22.16.12 jamesyonan: do you mean the reviews etc? jamesyonan 22.16.48 yes, the stuff on the github web interface (if any) that's not actually in the repo dazo 22.17.53 review comments and such things alonbl 22.17.59 jamesyonan: it is a metter of decision what service to use, as we discussion git only - there is no problem. If we want to go over the wiki, the pages are kept within git repository, so we can migrate too... bug tracking is something I did not investigate. dazo: we do the formal review at the mailing list.... peer review may be done using github interface, but submitting a complete patch and discussion should be in the mailing list. 22.18.40 vpnHelper 22.18.43 RSS Update - testtrac: cleanup: add .gitattributes to control eol style explicitly <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=f99d8fa79d538c42f2ebb54d8bc2a7f891ea09f9> || Ensure sys/un.h autoconf detection includes sys/socket.h <http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=a2d747bb0397c5837ec2c80ae9a3c3267acbdb2c> || cleanup: remove C++ dazo 22.18.58 that's a model I can agree to mattock 22.19.36 nice! andj 22.19.36 ok, github it is, I guess alonbl 22.19.46 dazo: I did not mean to change the model, just the technology jamesyonan 22.19.47 as others have pointed out, it's nice to preserve linkage between discussions and patches -- on github some of these discussions might exist outside of the repo dazo 22.20.26 As long as the summary of such discussions hits the ML ... I think that will be good enough ... but to encourage easier peer-review makes sense, esp. if that lowers the barrier to try to contribute to openvpn - and still have a good review regime 22.21.13 mattock 22.21.17 I think most of the discussions boil down to "why this <feature> makes sense" and "why was this implemented this way"... and I think the most important things could be in Git commit messages themselves 22.21.49 dazo 22.21.56 and when all those implementation details are sorted out ... the patch set is submitted to the ML, where it gets the final inclusion ACK mattock 22.22.11 sounds like a plan dazo 22.22.12 exactly andj 22.22.19 Move on to subsystems vs. features? cron2 22.22.46 have we agreed on anything yet? mattock 22.22.54 I think so alonbl 22.23.03 I opened organization https://github.com/OpenVPN, dazo, please send me your user so I can forward admin to you. mattock 22.23.03 host repos at GitHub, sync to SF.net cron2 22.23.18 ok as long as the wiki tells me where to clone from 22.23.26 mattock 22.23.37 cron2: I'll make sure that happens I don't want to remember stuff either 22.23.44 dazo 22.23.46 alonbl: I think mattock is probably the one who should have that .... as he is an official OpenVPN Tech person ... I'm just a community guy working here for free mattock 22.24.10 alonbl: what can an admin do? unlimited powers? 22.24.37 alonbl 22.24.45 mattock: creating repositories, deciding which teams, assigning people to teams, assigning teams to repositories, assigning privileges. mattock 22.25.13 and it's possible to hand out permissions to others as needed? alonbl 22.25.31 mattock: yes, you can keep me around to help... mattock 22.25.42 I don't mind doing that, doesn't sound like much of chore... knock knock cron2 22.25.49 *wants to be in the blue team* mattock 22.25.57 and jamesyonan definitely should have admin access, too alonbl 22.26.13 mattock: whatever you decide. mattock 22.26.34 hmm, I'm the leader now? anyways, we can discuss these details later 22.26.54 andj 22.26.59 anyway, let's sort out those details outside of the meeting 22.27.01 cron2 22.27.02 mattock: this is just to point out that's all your fault mattock 22.27.23 cron2: yes it is... sorry ok, subsystems vs. features? 22.27.44 cron2 22.28.40 I'm not seeing that "PolarSSL" or "IPv6" are more or less "feature vs. subsystem" than "routing", "IPv4" or "crypto" andj 22.28.40 I agree with the concept, I'm just a bit hesitant of placing someone in charge of every system... That way we have lots of little chiefs, and not one team cron2 22.28.59 "PolarSSL" is just a smaller subsystem than "crypto+openssl+polarssl" dazo 22.29.09 I agree that it would be beneficial for me to have some sub-maintainers ... who would be active reviewing stuff in their sub-modules ..... but those of us who are here have full time jobs, and limited time mattock 22.29.27 yeah, that's what I'm worried about most... cron2 22.29.41 *is happy to review patches for code paths that I do understand, which is mostly the "system dependencies" and "ip/routing" bits* andj 22.29.45 Thing is, people tend to have an area that they spend more time on anyway and I don't really think we need to formalise it 22.29.53 cron2 22.30.00 but I wouldn't want commit access, I'm not that good in git so I would mess it up dazo 22.30.40 cron2: it would be that you have commit access to your own tree .... and I would more "blindly" just merge in your tree into the public one(s) mattock 22.30.42 I think alonbl's point is valid, but as andj says, there might not be a need to formalize anything alonbl 22.30.42 cron2: you can have commit access to your shiny new github repository sending pull request to formal repository, so no need to be afraid. cron2 22.30.59 *does not want subsystem-specific trees - maybe come back to that idea when we have 10 people commiting on a regular basis to the "Network" subsystem and I could fully concentrate on review and merge* the question posed was "Do we want to allow direct commit access to official repositories for the subsystem maintainers?", and my response to that is "I do not want that" 22.31.25 alonbl 22.31.27 mattock: there is no need but without formalizing we will not have accountability. mattock 22.31.35 what we'd want is focus on (fairly large) subsystems (regardless of how that's achieved) cron2 22.31.35 i'm well aware that i can have my own git repos all day long andj 22.31.40 alonbl's point is definitely valid in the sense that we need to look at higher-level subsystems during modularisation alonbl 22.31.43 cron2: this is not the question. dazo 22.31.56 If there are someone now who wants to have responsibility over a specific code part ... I'm more than willing to help out in that regards ... but I think that request must come from the developer(s) itself ... not something we try to decide here and now cron2 22.31.57 alonbl: please bother to look at the agenda. This is one of the questions posed mattock 22.33.08 if everyone thinks it's a valid concern, it's just what came to my mind alonbl 22.33.22 cron2: who sorry, I did not want to comment this. What I was asking is what the role of the developers, who is actually maintain openvpn code? and how... after we answer these questions we can ask how one commit. cron2 22.33.33 dazo: as I said, I'm happy to review (as time permits) routing and system-dependent stuff, but I can't take full responsibility right now andj 22.34.19 I review and check stuff as I have time, and pay special attention to the crypto stuff in general mattock 22.34.31 alonbl: so besides accountability, what would having (formalized) subsystem maintainers give us in return? cron2 22.34.33 alonbl: indeed this is a good question, and one not easily answered. I can speak for myself, and the answer is similar to what andj just said (s/crypto/routing, ipv6, sysdep/) 22.34.56 alonbl 22.35.19 mattock: first it provides a firm skeleton of software project, maining we know who is developing what, and who can ACK what. mattock: then, it provides the responsibility of people to keep code intact, clean it up and improve it as a whole. 22.35.53 andj 22.35.56 alonbl: my point is though, I'm not sure we need such a firm skeleton at this point. Basically we're creating a skeleton, but leaving out the flesh 22.36.25 cron2 22.36.33 andj: +1 alonbl 22.36.39 mattock: it also provides a clear definition of the responsibility of a core developer to patches accepted by him, hence a complete release cycle. dazo 22.36.46 alonbl: I think it's fair to say that the current situation is that it's a shared responsibility ... those who are here today (jamesyonan, cron2, andj + d12fk who is absent today) are those who I trust very much, and it's a mutual trust that we all wants the best for OpenVPN mattock 22.36.51 I think this is the important part: "keep code intact, clean it up and improve it as a whole" cron2 22.36.53 we need to do that when we have 15+ active developers, not at "about 5" mattock 22.37.27 cron2: I hope GitHub helps us out with that andj 22.37.34 mattock: there's other ways to try to achieve code cleanups too though alonbl 22.37.46 cron2: we can do this with 1 (as james did in the past), so 5 are much better. mattock 22.37.47 yeah, my point exactly... dazo 22.38.04 mattock: it can fly both ways ... we can get more garbage patches ... and we can get more who reviews and better patches through that process andj 22.38.04 for example, by organising hacking sessions, where people pick a few pet peeves and fix them cron2 22.38.14 alonbl: you seem to prefer a standstill to any impurity. I want working software, and take some risks. alonbl 22.38.16 dazo: shared responsibility is no responsibility. mattock 22.38.21 dazo: very true, it remains to be seen dazo 22.39.06 alonbl: generally, I agree ... but I would say those of us who are here, honestly wants the best for openvpn and does indeed try to make things better mattock 22.39.09 alonbl: I would not go _that_ far, even though there's some truth to that alonbl 22.39.15 cron2: I think the openvpn project is too important to reach to a point it is unmaintainable... I believe that in current curse it will reach this state. mattock 22.39.39 ok, so we disagree on how to prevent that cron2 22.39.45 alonbl: anyone is free to rebase a "truly stable openvpn" based on 2.1 *wants openvpn with 21st-century-features, and you need to get some momentum for that* 22.40.03 alonbl 22.40.03 cron2: this is not the solution. cron2 22.40.21 alonbl: you do not want changes, that's the way to go jamesyonan 22.41.00 I don't think OpenVPN has yet grown beyond the point where making decisions by consensus is unreasonable mattock 22.41.00 ok, so can we agree that we all want to keep openvpn codebase clean and future-proof? alonbl 22.41.03 cron2: I do want changes! I just think that a change need to be maintained for long term. andj 22.41.14 Anyway, this is getting a little bitter mattock 22.41.41 andj: true, gather your nerves, guys alonbl 22.41.44 andj: what do you mean? cron2 22.41.59 alonbl: of course. I've been maintaining mgetty for 19 years now, so I know what that means (and what "drop-and-run" patches cause) alonbl 22.42.25 cron2: so why do you want this at openvpn? cron2 22.42.35 openvpn is doing well, and we're not heading into deseaster - to the contrary, with the buildbot structure and t_client test setup we're in much better shape now andj 22.43.10 But we do need to focus the community a little to get some needed cleanup done mattock 22.43.11 I would say we need to be careful _not_ to head into a disaster cron2 22.43.15 alonbl: you seem to imply that people that want to see progress do not understand that there is doom pending - I do understand that, and we're not in danger mattock 22.43.26 andj: again a good point andj 22.43.43 and splintering it into lots of little sub-communities isn't the fix we need jamesyonan 22.43.54 I like the approach where the larger and more disruptive a patch is, the more committment the submitter must show to its maintance before it's merged alonbl 22.44.23 what I saw in latest patches is that people who ACK are not aware of the consequences, nor follow up the release cycle. I think this is undesirable. cron2 22.44.30 uh. buildbot fail on freebsd... (because there is no polar ssl on those machines) mattock 22.44.36 actually, this topic is also related to the "ACK -> you take responsibility also" patch... unless we're arguing about that now which is related to "drop and run" patches 22.44.49 alonbl 22.44.51 mattock: right. andj 22.44.53 let's take this one step at a time, mattock That's a different discussion 22.45.05 mattock 22.45.09 yeah, not changing the topic, just pointing out cron2 22.45.10 alonbl: so standstill again, as there will always be patches where we can't see the full consequences right away? dazo 22.45.37 the important thing is to submit patches when things like that are noticed ... so that it can be fixed asap alonbl 22.45.39 Personally, I don't know any other community acting without a set of core developers who are long term developers responsible on the entire (or subset) of codebase... cron2 22.46.00 alonbl: you learn something new every day alonbl 22.46.04 dazo: by who? dazo 22.46.16 by those who see the issue mattock 22.46.29 well, openvpn project as we know it has a somewhat atypical history from jamesyonan only to current active developers 22.46.43 dazo 22.46.53 OpenVPN is special in that regard ... as jamesyonan was the only long term maintainer, but had a lot to do and couldn't keep up the pace with the community demands .... in fact, we were pretty close to openvpn forking - which would not be beneficial at all alonbl 22.47.03 cron2: right... and I followed a lot of time since switched into "community based" and I believe it is not working, a lot of changes were introduced and merge, while code complexity grow in greater order. dazo 22.47.30 but those of us who are active here today, are people who stood up and took some responsibility, to try to make this work and help jamesyonan with the community side of OpenVPN mattock 22.47.31 alonbl: it's community based andj 22.47.36 Which means that it's time for cleanup, not organisation changes cron2 22.47.39 well, as the rest of us seems to believe it *is* working, can we close this topic now? dazo 22.47.47 and we avoided a fork so far mattock 22.48.04 andj: agreed, cleaning up the codebase should be our priority ecrist 22.48.09 *is here, too* mattock 22.48.14 hi ecrist! ecrist 22.48.16 just for the record. dazo 22.48.19 hey! andj 22.48.20 evening mattock 22.48.28 yeah, you got to the record alright alonbl 22.48.37 dazo: currently james is the only core developer, responsible on the entire code base, including whatever was committed. There is no one else... there are people that helps in specific features, but that's it. mattock 22.49.25 alonbl: I think that's because james is the only person who knows the codebase well enough i.e. history of the project 22.49.41 dazo 22.49.45 and that's why we consult him on things we feel we do need far more understanding of jamesyonan 22.49.47 alonbl: no I wouldn't agree with statement that I'm the only core developer alonbl 22.49.52 mattock: no, it is because james is the only one that is currently accountable. mattock 22.50.36 the problem I see with formalized subsystem maintainer approach is lack of resources to do it properly andj 22.50.43 anyway, this discussion isn't really heading anywhere productive anymore, can we move on to ack-> maintenance or openvpn 2.4? cron2 22.50.48 dazo: could you commit the andj patch about havege_rand, please? buildbot is failing on up-to-date polarssl alonbl 22.51.03 Guys, it is very difficult to discuss this in IRC, better to present argument in full. cron2 22.51.04 andj: what polarssl version do I want to install on the *BSD buildslaves? dazo 22.51.07 cron2: sure! I'll dig it up andj 22.51.14 1.1.2 mattock 22.51.19 yeah, let's discuss this later another time on the ml andj 22.51.25 ehrm 1.1.1 dazo 22.51.31 1.1.x alonbl 22.51.59 jamesyonan: I will be glad if you can give some example of other people maintianing not a feature but a complete significant piece of code. mattock 22.52.16 ...and when we discuss this again, we should take a look at the problems and then figure out what's the best way to solve it cron2 22.52.17 this distinction is ridiculous in itself mattock 22.52.37 it may be subsystem maintainers or something else entirely... let's keep an open mind, shall we cron2 22.52.39 I consider "the #ifdef FREEBSD" bits as "significant piece of code" dazo 22.52.50 +1 jamesyonan 22.53.05 alonbl: polarssl, ipv6, platform specific code outside of linux and windows alonbl 22.53.11 cron2: no if we can reduce the #ifdef FREEBSD and merge them more common with the #ifdef LINUX. cron2 22.53.26 alonbl: again you don't understand that this cannot be done mattock 22.53.37 next topic, shall we? andj 22.53.45 please mattock 22.53.48 https://community.openvpn.net/openvpn/wiki/Topics-2012-04-26#ACK-maintenanceresponsibility cron2 22.53.48 please vpnHelper 22.53.50 Title: Topics-2012-04-26 – OpenVPN Community (at community.openvpn.net) mattock 22.54.01 this one is an interesting proposal alonbl 22.54.02 jamesyonan: these what I call features. As if we introduce a proper ip and routing subsystem and we have a maintainer the code would have been cleaned up and not get ever more complex. andj 22.54.04 I for one would be more hesitant to ack mattock 22.54.27 yes, most probably would dazo 22.54.39 andj++ mattock 22.54.48 I think a lot depends on "what patches need to be ACKed" andj 22.54.52 Now, I wouldn't mind checking a small patch in a completely unrelated branch cron2 22.54.58 if I ack short things, like "this is an obvious bug to ifconfig-call on XXXBSD", I am fine with maintaining the result if I ack things like "this buildsystem rewrite looks useful", I'm most defintely not going to accept responsibility for it 22.55.18 dazo 22.55.19 I think I said in an discussion earlier, that the ACKer is partly responsible if issues appear ... but the core responsibility of a patch is the author of the patch cron2 22.55.34 ("full" responsibility, that is) andj 22.55.59 any acker takes responsibility cron2 22.56.00 I *do* try to understand the patch, and as such, do take responsibility, but wouldn't end up as the build system maintainer alonbl 22.56.04 cron2: because of this I am doing the tun thin: https://github.com/alonbl/openvpn/compare/master...tun, so you can maintain only freebsd without implications. dazo: this is short term thinking, not long term. 22.56.29 dazo 22.57.13 well, as james said ... if you have a large patchset ... then you need to show much more efforts in getting things accepted, show that you're thinking long term about it mattock 22.57.29 alonbl: how would we trace the code back to the ACKer, i.e. how would we know who's responsibility a certain piece of code is? andj 22.57.37 you're basically demanding someone to commit a significant chunk of time, in return for volunteering dazo 22.57.38 but I don't think we should expect a long term commitment to a 2-liner patch andj 22.57.57 to review a patch mattock 22.58.09 alonbl: what kind of patches are you thinking primarily? alonbl 22.58.10 mattock: exactly because of that I suggest the subsystem model, at any given time we should know who is maintianer of what piece of code, and this person need to maintain the implications. mattock 22.58.30 yes, in that model this might make sense or even "would make sense" 22.58.48 dazo 22.58.56 jamesyonan: do you have a chance to review this patch set from andj? http://thread.gmane.org/gmane.network.openvpn.devel/6210 vpnHelper 22.58.57 Title: Gmane Loom (at thread.gmane.org) alonbl 22.59.01 dazo: right. if one ACK it should also make sure to fix the damn thing if patch author disappears. mattock: in most cases patches that introduces new features to the already featured openvpn. 22.59.29 cron2 22.59.34 alonbl: so you want us to never ACK anything from you again, in case you disappear? andj 22.59.47 dazo: note that that patch set was acked, but needed a change to remove < 1.1 polar support dazo 23.00.16 andj: uhm ... oh dear, is my backlog that bad now cron2 23.00.24 andj: meh, polarssl.org is giving me a "Forbidden" andj 23.00.37 lol it worked 2 mins ago 23.00.46 mattock 23.00.54 maybe it's too popular? cron2 23.01.08 oh, now it's "Requirement error" andj 23.01.12 I think he might be updating alonbl 23.01.13 cron2: yes. I expect whoever ACK a patch of mine to be able to maintain it if I gone, or, and this is a big or, declare I am the maintainer of the (for example) build system. mattock 23.01.13 or running on Pentium 1 60Mhz alonbl: what if the ACKer is gone also? 23.01.43 dazo 23.02.25 alonbl: I can bring up two concrete examples .... we have two features which have been requested for, which is not applied to the tree .... vlan tagging support, which depends on a passtos feature patch set ... those are not included just for the reasons you ask for ... we don't have the knowledge to fully support it in the community, and the patch authors are not much active andj 23.02.34 ah, btw: 1.1.2 is out now dazo 23.02.36 *is lagging in the discussion* andj 23.02.43 heads up: it's a security release mattock 23.02.46 dazo: good examples alonbl 23.02.47 mattock: exactly because of this we need a set of properly defined core developers, to know that in every point in time we can cover the complete openvpn code base or we need to seek some experteeze to be sane again. mattock 23.04.00 alonbl: this makes sense in theory, what worries me is whether it's doable in practice, with our (current) resources alonbl 23.04.05 dazo: so first we have a fundemental problem, we do not have the knowledge to support the tun and bridging, right? dazo: so if we have a problem in this regard, how can we maintain even more complex code? 23.04.26 cron2 23.04.28 sure we have dazo 23.04.50 I wouldn't exclude james just because he isn't active on the ML cron2 23.05.01 we do not have the manpower to fully investigate the implications of adding vlan tagging on all supported platforms alonbl 23.05.05 dazo: refering to me? dazo 23.05.17 alonbl: yes alonbl 23.06.19 cron2: it is entirely different... there are X resources for somoene to develop, test and perfect a patch, and different resources to maintain. If we can maintain but not develop and test it is OK. dazo: so in this case james should ACK. 23.06.40 dazo 23.06.51 and he does, when we have our meetings mattock 23.07.17 one of the primary reason for the meetings, btw jamesyonan is our "mentor" so to speak 23.07.35 cron2 23.07.43 *is out of that discussion now - I don't have time for that, and I fully trust dazo and james to do the right thing, *and* I believe that we're on a good track (if anything, we're too *slow*)* andj 23.07.50 anyway, I've put in my 2c. I think we're doing ok organisationally, and we need to focus 2.4 on cleanup/modularisation alonbl 23.07.51 dazo: so james also take the accontability, just like I outlined, if we have a problem, james will need to provide a solution if nobody else will be able to. andj 23.08.06 cron2: lol cron2 23.08.27 andj: what can I say? This isn't going anywhere, and I need to go to bed in 20 minutes mattock 23.08.27 alonbl: that's how it gone so far andj 23.08.43 I'm going to head of to bed soon as well cron2 23.08.47 (and polar 1.1.2 isn't building with "make" so now I need to get cmake to the buildslaves *grumble*) andj 23.08.50 WARNING: http://polarssl.org/news alonbl 23.08.50 mattock: right, so we have one core developer, james. vpnHelper 23.08.51 Title: News overview - PolarSSL (at polarssl.org) jamesyonan 23.09.12 alonbl: a lot has changed since 2.1 -- since then, the project has evolved into a real community structure with multiple developers dazo 23.09.22 alonbl: mattock said it well, james is our mentor ... and he has put some trust that those of us here today can do a reasonable job ... and we (I) sure hope he raises his voice if he sees something goes in the wrong direction from what he likes andj 23.09.40 cron2: make doesn't work? cron2 23.09.58 make: don't know how to make test_suite_aes.c. Stop (it compiles a few things, but then stops with that error) 23.10.13 mattock 23.10.28 cron2: you don't need cmake for polarssl alonbl 23.10.30 jamesyonan: james, I follow this process, and tell you that nobody is responsible to any piece of code apart of you, you cannot compare it to any other open source community out there. dazo 23.10.40 andj: would you mind help me find those patches we're lacking .... my brain capacity doesn't scale well with this parallel discussion andj 23.11.21 dazo: what patches? mattock 23.11.24 alonbl: probably not at subsystem level as defined by you jamesyonan 23.11.27 alonbl: it's simply not true, other developers have made major structural changes to the code base dazo 23.11.33 andj: PolarSSL 1.1 stuff alonbl 23.11.34 jamesyonan: It is just like you tell me that in KDE, someone will maintain the ipv6, someone else the encryption, there is somoene that cares about the fonts, but nobody actually maintain the core. andj 23.11.37 dazo: It's these ones: http://thread.gmane.org/gmane.network.openvpn.devel/6210 vpnHelper 23.11.38 Title: Gmane Loom (at thread.gmane.org) andj 23.12.03 cron2: it builds fine on my machine with make cron2 23.12.18 andj: tarball? dazo 23.12.22 andj: and then it was another thread as well? http://thread.gmane.org/gmane.network.openvpn.devel/5689 ? andj 23.12.22 yeah vpnHelper 23.12.23 Title: Gmane Loom (at thread.gmane.org) andj 23.12.36 those where the old ones cron2 23.12.40 which one? I have polarssl-1.1.2-gpl.tgz andj 23.13.01 "wget http://polarssl.org/code/releases/polarssl-1.1.2-gpl.tgz"; mattock 23.13.03 andj, cron2: we're trying to argue here without any resolution/consensus in sight alonbl 23.13.06 jamesyonan: I can take this offline and demonstrate you the complexity introduced, and the fear of people to touch existing lines of codes, hence adding more complexity. cron2 23.13.10 andj: yes, that's what I got andj 23.13.20 mattock: we gave up, I think cron2 23.13.26 andj: bsd make, tho andj 23.13.32 aha, that might be it mattock 23.13.43 alonbl: this brings us to 2.4 release which at least I and andj think should focus on cleaning up this stuff 23.14.00 new features that were introduced 23.14.13 can we agree on that? 23.14.21 andj 23.14.55 Mostly, I think we should focus on refactoring, so not just new features, but also splitting large, cumbersome modules into multiple leaner modules mattock 23.15.01 and during that release cycle, fix the issues you've pointed out / will point out / look at the big picture cron2 23.15.12 andj: indeed fbsd90.ov$ gmake Generate test_suite_aes.c 23.15.15 *is fine with "have 2.4 the great clean up"* 23.15.50 dazo 23.15.52 andj++ andj 23.16.07 But: there's another side to that coin: 2.3 should be frozen soon then 23.16.13 alonbl 23.16.16 I promised to help with cleaning up the syshead usage, so this can be done either in 2.3 or 2.4, do not care which. Already started: https://github.com/alonbl/openvpn/compare/master...syshead vpnHelper 23.16.18 Title: Comparing master...syshead · alonbl/openvpn · GitHub (at github.com) mattock 23.16.28 alonbl: thanks! cron2 23.16.30 andj: ++ andj 23.16.36 alonbl: despite the arguments I really appreciate the clean up work! 23.16.44 mattock 23.16.48 andj: agreed, we should push out 2.3 a.s.a.p. dazo 23.16.53 absolutely! alonbl 23.16.59 I also created modular interface for the tun https://github.com/alonbl/openvpn/compare/master...tun, need help in testing it at *BSD. andj 23.17.04 and I think they're going well mattock 23.17.15 alonbl: you're one coding machine I have to say andj 23.17.16 alonbl: I'd prefer to put those into 2.4 mattock 23.17.32 although I think you had some of the buildsystem stuff ready before it went public, didn't you alonbl 23.17.58 andj: Thanks! I am trying my best to lower the complexity. cron2 23.18.17 *doesn't want major tun.c changes before 2.3 - I have all platforms working for all supported protocols now, and getting that back after a rewrite will take time* alonbl 23.18.41 mattock: I did not have anything... Just an attempt to convince James to do this about 6 years ago... mattock 23.18.41 alonbl: I think the 2.4 cleanup cycle will also help us (me not included) get to know openvpn in more details... and thus address your concerns regarding core developers alonbl: ok, then you're the coding machine as I stated 23.18.58 ok, end the meeting now and continue later? 23.19.43 alonbl 23.19.46 mattock: thanks, this will be great. cron2 23.19.51 haha mattocks buildslave ran out of disk space 23.19.56 andj 23.20.02 lol mattock 23.20.03 cron2: damn which one? 23.20.05 andj 23.20.14 cron2: have you found the polar make issue? cron2 23.20.15 ubuntu-1004-amd64 dazo 23.20.15 alonbl: one of the core problems in the current code base, is that it's not easy to follow all the code paths and understand well how it stays together ... which is why it's not easy to get more people involved, as it requires quite some guts ... but as andj said, I also appreciate your clean up work ... and I believe you help reducing that complexity, to make it easier to see the bigger picture, with your cleanup patches mattock 23.20.22 cron2: ok, need to fix that then cron2 23.20.41 andj: it works with gmake - these test_suite_*.c are built on-the-go, and the rules for that seem to be bsd-make-incompatible mattock 23.21.09 alonbl: thanks for attending the meeting today, even though I know you're not very fond of IRC cron2 23.21.12 didn't look, just ran gmake, and it now builds andj 23.21.15 I'm sure Polar is willing to fix that alonbl 23.21.29 dazo: thanks! the difference in my approach is that I prefer to do the cleanup before significant merge... dazo 23.21.30 alonbl: so I hope that this cleanup will help solve more of those issues you rightfully do point out ... but it's not solved over night ... and we're not all as code efficient as you seem to be mattock 23.21.33 very useful, we made good progress and didn't end up choking each other... although the physical distance helped somewhat andj 23.21.34 thanks everyone cron2 23.21.38 andj: well, the README could just say "needs gmake" and that would be fine with me heh, we're not done yet 23.21.53 there's one last item on the agenda 23.22.03 andj 23.22.13 uh oh mattock 23.22.21 cron2: oh, the infamous connectivity tests damn 23.22.25 dazo 23.22.31 alonbl: yeah, I would also normally agree to that ... but we seriously need much of the features we have merged, to be relevant in the future .... so it's a give-and-take situation, not ideal - but that's the reality mattock 23.22.38 I thought I managed to escape those cron2 23.23.10 mattock: yeah, really. I can set this up for you for my buildslaves, as I have the tests + certs all done already. Just send me an mail that explains which files need to be where so buildbot can pick them up dazo 23.23.17 *looks at the clock and realises he needs to run for the train home* cron2 23.23.18 (t_client.rc, certs, etc.) andj 23.23.24 What I'd really love in 2.4: unit tests for a few key modules mattock 23.23.27 cron2: can you setup the test server? cron2 23.23.53 mattock: didn't you have that already? mattock 23.23.59 well, I have a VM dazo 23.24.04 Thanks all for a good meeting! mattock 23.24.15 nothing's configured yet, after our previous test server was taken offline cron2 23.24.25 mattock: where's the config from the old test-server? andj 23.24.31 need to run as well thanks everyone 23.24.35 cron2 23.24.36 g'night, folks mattock 23.24.39 cron2: good question... I fear it got lost bye guys! 23.24.42 summary tomorrow 23.24.45 from me 23.24.47 L'utente dazo è ora conosciuto come dazo_afk 23:24 alonbl 23.25.01 bye cron2 23.25.03 mattock: *sigh*, ok, I'll do it again mattock 23.25.20 I'd appreciate that a lot, given you got more experience on the matter I'll handle my buildslaves, that's a handful 23.25.27 cron2 23.25.32 bah, that's just "setting up a handful of openvpn servers" mattock 23.25.45 true, but my past performance in setting up the test server(s) is not especially convincing 23.26.15 cron2 23.26.26 mattock: will buildslave/configure find polar when it's installed in /usr/local/{include,lib}/? fbsd90 now has polar 1.1.2 23.26.31 mattock 23.26.31 frankly, I've sucked cron2 23.26.51 mattock: well, we need incentives. Like "we'll saw off some other fingertips"... mattock 23.26.57 lol I used a sharp kitchen knife, less painful 23.27.06 would that be an option? 23.27.10 cron2 23.27.22 spoon mattock 23.27.26 although... that would make it even slower to setup future test servers "because it hurts more?" 23.27.35 cron2 23.27.40 then we need to start with the toes. blunt spoon mattock 23.28.48 cron2: so test server before 2.3-final? I think that's a fair goal 23.28.55 cron2 23.28.56 mattock: most definitely mattock 23.30.07 ok, what if I setup the VM with ecrist, and you take over as our primary FreeBSD developer? I got access to the ESXi host 23.30.27 cron2 23.30.40 no time to take up anything new, but as soon as the VM is running, I can setup the test servers mattock 23.30.48 yeah, that's what I meant I'll give you SSH credentials and a pre-installed FreeBSD box, and you setup the test servers 23.31.05 and I'll setup my buildslaves accordingly 23.31.11 cron2 23.31.25 ok mattock 23.31.43 my current buildslaves are IPv4 only, unfortunately... we should definitely have a Linux IPv6 buildslave, too 23.31.53 cron2 23.31.57 that does not matter for testing IPv6 transport s/transport/payload/ 23.32.10 mattock 23.32.16 yep cron2 23.32.23 but for testing *transport*, we need external v6 as well, yep mattock 23.32.43 I got one VM I could probably use, I've been trying to get rid of it (unsuccessfully, I might add) it probably has IPv6, or can have at least 23.32.55 ecrist: there? 23.33.14 cron2: I'll try to have the server setup tomorrow 23.33.32 cron2 23.33.54 cool mattock 23.33.55 if there are no obstacles in ESXi I should manage e.g. "wrong credentials" 23.34.05 ok, time to go to bed, see you later!
