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 15th Mar 2012 Time: 18:00 UTC Planned meeting topics for this meeting were on this page: <https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15> 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 andj, dazo and mattock participated in this meeting. -- This meeting was a sprint where Alon Bar-Lev's "Build revolution" patchset was reviewed. The ACK status before the meeting: <https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15?version=16> And after the meeting: <https://community.openvpn.net/openvpn/wiki/GenericBuildsystemIntegration?version=10> NOTE: there's now a separate page for the patch status. Please do not edit the topic page anymore. -- These patches still lack a code-ACK: PATCH 48/52 cleanup: move console related function into its own module URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5812 PATCH 49/52 build: move wrappers into platform module URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5822 -- These patches were ACKed, but may need some modifications later: PATCH 16/52 build: we need the sample.ovpn in future URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5763 PATCH 39/52 build: proper lzo detection and usage URL: http://thread.gmane.org/gmane.network.openvpn.devel/5772/focus=5811 The proposed changes will be discussed on the openvpn-devel mailing list. -- Decided to discuss this topic on the mailing list: "Move official openvpn project repositories into github" -- A full list of ACKs will be sent to the mailing list later. --- Full chatlog as an attachment -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock
mattock 20.03.40 ok, who is here? andj 20.03.56 (half) mattock 20.06.02 I mailed James but got no response I'll poke him if he does not come soon 20.06.13 dazo 20.06.55 oh, it's that time already! mattock 20.08.15 yep mailed James 20.08.55 let's begin 20.08.56 topic list and patch status here: https://community.openvpn.net/openvpn/wiki/Topics-2012-03-15 20.09.22 vpnHelper 20.09.24 Title: Topics-2012-03-15 â OpenVPN Community (at community.openvpn.net) mattock 20.09.56 dazo: are there dependencies between the patchsets? the openvpn-gui patchset is independent, but the rest... 20.10.23 dazo 20.10.24 mattock: yeah, it is ... build revolution goes first ... but not sure about the two others mattock 20.10.36 let's start with the build revolution one shall we? 20.10.40 dazo 20.10.47 *need 5 min* mattock 20.10.58 ok patch 03/52 is the first un-ACKed one 20.11.08 I acked everything I could, but I skipped those patches which required non-trivial autotools knowledge 20.11.56 cron2: there? 20.12.03 andj 20.12.48 03 seems relatively trivial, but as I said I'm half here... My development laptop isn't, so no compiling for me today mattock 20.14.10 andj: is that an ACK? andj 20.14.33 although slightly hesitant without being able to compile it, yes ACK mattock 20.14.34 ah, it _is_ trivial I think we should fix any issues later... I've tested the buildsystem in it's entirety and it worked fine 20.15.11 that is, it's really hard to tell if a patch works or not by just looking at it 20.15.27 added ACK from me and anj 20.16.40 andj 20.16.42 missed patch 01/52 20.16.50 andj 20.17.19 ehrm, not sure about that one mattock 20.17.24 yeah, me neither andj 20.17.27 why shouldn't it contain -? mattock 20.17.42 no clue, that's why I didn't ACK it earlier... dazo 20.17.49 I think that's more a recommendation ... f.ex. rpm packaging don't like that andj 20.17.51 Is that a technical issue? or is it a pedantic issue dazo 20.18.02 more pedantic mattock 20.18.03 hmm, yes, rpms are picky andj 20.18.24 aren't debs picky in the opposite way? mattock 20.18.28 I wonder what would this change affect... dazo 20.18.29 of course, it's far simpler to do rpm packages if we don't have '- mattock 20.18.37 actually debs don't care afaik dazo 20.19.06 yeah, I've never heard anyone complain about _ in deb earlier ... that was used throughout the 2.1 beta and RC mattock 20.19.18 i.e. they check the version by sorting... so that 2.1-1 is older than 2.1-2 dazo 20.19.26 correct mattock 20.19.27 and 2.1a is older than 2.1b so I don't mind this change, and if it helps with rpms... why not 20.19.41 dazo 20.19.47 agreed I'm ACKing it 20.19.50 mattock 20.19.52 ok next patch: 10/52 20.20.07 dazo 20.20.19 (If I want a battle with Alon, it better be something worth fighting for mattock 20.21.23 lol dazo 20.21.48 andj: patch 3 ... it's really redundant ... #include "forward.h" 20.21.49 #include "configure.h" 20.21.49 andj 20.21.50 ack, I think he's right dazo 20.21.50 -#include "forward.h" forward.h is included twice in the same file 20.22.09 mattock 20.22.10 ah, alon has updated the topic page with new links... very nice ok, 10/52 ack from andj 20.22.51 and dazo? 20.22.56 dazo 20.22.59 mattock: you skipped 5/52? mattock 20.23.07 oops was this 5/52 or 10/52 you just acked? 20.23.17 andj 20.23.34 10 mattock 20.23.34 me confused ok 20.23.35 dazo 20.23.49 mattock: I need to dig further on 5 .... unless d12fk is around and can look at it andj 20.23.54 and for 05, I don't know... What's the difference? widechar vs utf? 20.24.02 dazo 20.24.03 *dunno* andj: seems so! 20.25.17 http://msdn.microsoft.com/en-us/library/hf4y5e3w%28v=vs.80%29.aspx 20.25.17 vpnHelper 20.25.18 Title: printf Type Field Characters (CRT) (at msdn.microsoft.com) mattock 20.25.19 skip that one, move to 13/52? ah, let's wait 20.25.27 andj 20.26.06 is cmd a widechar? mattock 20.26.52 no clue dazo 20.27.07 WCHAR *cmd = wide_string (a->argv[0], &gc); yes, it is 20.27.10 so that's an ACK from me at least 20.27.19 andj 20.27.20 ack mattock 20.27.59 ok dazo 20.27.59 mattock: now we can take next mattock 20.28.04 nice 13/52 20.28.12 andj 20.28.39 no idea dazo 20.28.58 wow ... that's heavier *recalls this one'* 20.29.08 I've ACKed it already ... didn't write any comments, but remember digging up info about that attribute stuff 20.30.00 it makes sense 20.30.03 (I acked it in the first round of patches Alon sent) 20.30.31 andj 20.30.42 skipping an ack, leaving it up to dazo dazo 20.30.44 (there it is patch 8/35) *ACKs 13/52* 20.31.05 mattock 20.31.36 ok 14/52 20.31.55 andj 20.32.22 very pedantic dazo 20.32.29 ACK on 14/52 ... I've fought that kind of battles before .... I don't mind that change at all mattock 20.32.31 this sounds like dazo stuff (plugin -> dazo) dazo 20.32.56 it's just renaming the plugin directory to plugins andj 20.32.58 assuming no diffs, don't carte *care 20.33.01 dazo 20.33.07 yeah, exactly mattock 20.33.11 15/52 dazo 20.34.16 ACK andj 20.34.35 ack, and quite happy with those fixes dazo 20.34.44 agreed mattock 20.35.00 16/52 I had some comments about that one 20.35.09 trivial and useful, but why have a separate directory from windows example files 20.35.26 this boils down to: all sample files in the same directory or windows samples in a different directory 20.37.08 dazo 20.37.09 that file config seems to be Windows specific, for some reasons ... so I'd say ACK, and we'll improve this further later on mattock 20.37.22 yep, makes sense not a showstopper 20.37.25 22/52 20.37.41 dazo 20.39.08 this makes things more readable in the end ... and my last attempts building it, it seems to work very fine ... so I don't have any arguments not to ACK it andj 20.39.10 are those still used? yeah, sure, ack for more readability 20.39.29 mattock 20.39.46 ok dazo 20.39.55 I believe so ... Alon would not leave in old cruft which would not be useful ... at least that would surprise me big time mattock 20.40.24 yes, he's been removing old cruft quite nicely 23/52 20.40.48 dazo 20.41.14 ACK ... basically just cleaning up formatting and making it more readable andj 20.42.03 ack what are the dnls for? 20.42.08 dazo 20.42.29 that's m4 remarks ... m4 variant of # or /* */ I think it is also added at the end of some lines which are expected to continue 20.43.00 like \ in shell scripts 20.43.06 andj 20.43.07 aha mattock 20.43.51 ACK 23/52 by dazo andj 20.43.53 thanks, I was wondering why you would want to comment an empty line mattock 20.43.56 then 24/52 dazo 20.44.01 http://info2html.sourceforge.net/cgi-bin/info2html-demo/info2html?%28m4%29Dnl vpnHelper 20.44.02 Title: Info: (m4) Dnl (at info2html.sourceforge.net) dazo 20.45.01 m4 is such an odd macro language .... and one of the reasons I don't like sendmail much ... but that's another story mattock: ack on 24/52 from me 20.46.13 mattock 20.46.54 hmm, I wonder if there's are benefit in sending an email for each patch we ACK here andj 20.46.58 I'm going to stay out of the m4 stuff, I'm not certain enough there mattock 20.47.10 dazo: ok 25/52 then 20.47.28 dazo 20.47.56 mattock: if you mail a summary of what we acked (preferably with a gmane link to each patch) ... I'll give a summary of applied patches to the 0/52 mail from Alon mattock 20.48.32 I would prefer it without the gmane link, unless somebody knows how to properly automate that such a pain... 20.48.41 dazo 20.49.43 okay, I'll help you with that we'll split the list in two mattock 20.50.33 you're forgetting I get paid for it save your energy for something less trivial 20.50.46 I can do the links if they're important, I was just feeling lazy 20.50.59 anyways, back 25/52? 20.51.11 back to... 20.51.18 dazo 20.51.32 *find hacking C code much more trivial than digging up URLs * 20.51.40 mattock 20.52.31 off-topic: when there's a C coding course at the university, I'll take it for sure then I can start writing code with tons of buffer overflows 20.52.53 andj 20.53.06 *cheers at buffer overflows* dazo 20.53.21 hehe mattock: I'm ACKing 25/52 (palindrome, btw) ... don' 20.54.01 t see any issues here 20.54.06 mattock 20.54.08 andj 20.54.19 lzo-stub going out? mattock 20.54.25 26/52 claims to be trivial what _is_ lzo-stub? 20.54.33 andj 20.54.52 oh wait, comes back later "don't compile LZO compression support but still allow limited interoperability with LZO-enabled peers" 20.55.01 dazo 20.55.22 that's a wire protocol support so a client which don't have LZO libs, but compiled with lzo-stub can communicate with a server which has lzo enabled mattock 20.55.30 does AC_DEFUN mean making an AC power outlet less fun? sorry, had to say it 20.55.39 dazo 20.55.41 defunction? andj 20.55.42 dazo 20.56.35 alons claims that "first pass of trivial autotools changes" == 15 files changed, 738 insertions(+), 757 deletions(-) mattock 20.56.44 ah, 38/52 was the lzo-stub one dazo 20.56.56 I wonder what is un-trivial then ... mattock 20.58.01 actually, I think 26/52 follows the same standards Alon has used elsewhere I recall ACKing some even less trivial patch like this 20.58.11 I mean, even more trivial 20.58.18 I think this is one of those patches: "ACK now, fix later if necessary" 21.00.07 or alternatively, clone Alon's repo and see what the files look like in there 21.00.25 dazo 21.00.31 It's again just to improve readability and cleaning up ... so ACK from me mattock 21.01.04 ok andj 21.01.05 yeah, can't spot anything deadly either ack 21.01.07 dazo 21.01.22 the autotool files are kind of easier to tackle ... you cant break openvpn if autotools break, basically andj 21.01.48 No 29/52? I'm sure we can find a way 21.02.09 mattock 21.02.10 andj: I think that one has gone missing andj 21.02.42 should be that one: https://github.com/alonbl/openvpn/commit/f26b8c6e498184eb53dd74eff40f205358e72404 vpnHelper 21.02.43 Title: build: standard directory layout · f26b8c6 · alonbl/openvpn · GitHub (at github.com) dazo 21.03.14 yupp ... it's the mailing list too ... so just a wiki bummer mattock 21.03.40 did you receive the mail? I can't find it from my inbox or from gmane andj 21.03.48 those moves are going to be fun dazo 21.04.13 ahh! He sent a direct copy to me, as it was rejected by the ML .... 5.7 MB (my mailfilter moved it my folder for openvpn stuff) 21.04.34 andj 21.04.37 anyway, the github interface is _much_ cleaner mattock 21.04.39 ok, I'll add link to the topic page andj 21.04.39 for that one dazo 21.06.02 yeah, fair enough ... it'll be "sealed" with the git commit ID when it gets applied, and I'll provide subject and commitish for my "applied report" mattock 21.06.52 29/52 on topic page andj 21.07.05 ack, with compliments for cleaning that up mattock 21.07.18 adding ACK and compliments dazo 21.07.33 this one might be trickier to tackle, as here you can actually change the code in this move ... I don't believe Alon did it ... but I'll add an extra check .... shasum of all files before and after the move andj 21.07.56 just check the github patch it shows no changes to the source files 21.08.06 https://github.com/alonbl/openvpn/commit/f26b8c6e498184eb53dd74eff40f205358e72404#diff-71 21.08.10 vpnHelper 21.08.11 Title: build: standard directory layout · f26b8c6 · alonbl/openvpn · GitHub (at github.com) dazo 21.08.57 ahh nice andj 21.09.08 daoz: the overview at the top gives only moves, really clear interface btw dazo even 21.09.15 dazo 21.10.04 ahh ... git show --stat f26b8c6e498184eb53dd74eff40f ... confirms the same mattock 21.10.04 very nice ACK? 21.11.12 oh, did we ACK that already 21.11.27 29/52, that is 21.11.41 30/52 would be next 21.11.49 dazo 21.12.45 *wonders what his thunderbird is doing ...* ahh ... chewing on the big patch 21.13.01 mattock 21.13.15 ah, in 30/52 Alon is adding a Windows resource file for openvpnserv.exe dazo 21.14.08 I don't know enough about Windows to be able to tackle this one mattock 21.15.09 looks ok to me dazo 21.15.29 if you ack it, I'll apply it mattock 21.15.37 well, I don't see why it would be an issue I'm just wondering if the COMPANY_NAME should be corrected 21.15.53 andj 21.16.10 I was wondering about the copyright mattock 21.16.29 yeah, that too dazo 21.17.07 OpenVPN Project is kind of making it vague ... it's not just the company, but to mention all copyright holders that would be too much mattock 21.17.26 yeah, it has to be like "some main entity and contributors" or similar 21.17.28 ecrist 21.17.39 everything I do, I attribute to 'OpenVPN Community' mattock 21.17.46 "OpenVPN Technologies, Inc. and contributors" maybe? andj 21.17.55 Community sounds reasonable mattock 21.17.55 or James Yonan and contributors ecrist 21.18.13 I'm opposed to attributing anything to the corporation or to James specifically 21.18.17 mattock 21.18.25 I wouldn't expect anything less ecrist 21.18.53 not sure what that means mattock 21.18.55 in this post 2.3-alpha1 context attributing copyrights to James and/or the company would be somewhat questionable dazo 21.19.07 mattock: let's ACK this one, and rather fix this later on with a better wording .... OpenVPN Project is vague enough, and keeping some kind of balance L'utente ecrist ha lasciato la stanza 21:19 andj 21.19.41 ecrist disagrees? dazo 21.20.07 mattock: actually, in post 2.2 releases .... we had quite a big amount of community patches there too andj: he probably clicked the wrong button 21.20.17 mattock 21.20.24 dazo: yep, ACK andj 21.20.25 I know L'utente ecrist è entrato nella stanza 21:20 mattock 21.20.33 and in 2.3 even more patches dazo 21.20.40 yeah mattock 21.20.48 ecrist: for a while I was worried I made you angry or something ok, let's move on 21.21.05 31/52 21.21.57 dazo 21.22.56 *brb* mattock 21.22.57 I think that one makes sense, knowing Alon's general approach andj 21.23.03 ack mattock 21.23.32 32/52 as a sidenote, it would be interesting to do a copyright analysis of the codebase 21.24.01 dazo 21.24.04 yeah, ack mattock 21.24.08 and make some piecharts dazo: would git be the tool for that job? 21.24.17 33/52 is next 21.24.54 dazo 21.24.56 well, if you use 'git blame' on each file, you can summarise number of lines per author .... mattock 21.25.32 nice I was not sure what Alon meant by "I take another approach and detect dependencies as atoms." 21.26.16 so I did not ACK 33/52 21.26.20 andj 21.27.37 ack for 32 21.27.46 dazo 21.27.49 ACK on 32/52 mattock 21.27.51 ok dazo 21.28.17 ack on 33/52 mattock 21.28.26 updating andj 21.28.34 ack L'utente ecrist ha lasciato la stanza 21:28 mattock 21.28.57 34/52 I think ecrist has bad connectivity 21.29.03 dazo 21.31.22 ack on 34/52 .... even though, it's just a cursory look over it ... it tests for the proper things, as I can see ... and basically cleans up again mattock 21.31.41 it seems most of the changes follow the same basic pattern which is nice 21.31.46 dazo 21.32.03 yepp ... makes it easy to review andj 21.32.08 ack in the same way mattock 21.32.17 39/52 andj 21.33.01 nack on disabling lzo by default mattock 21.34.26 I recall discussion about that... I wonder if that has been changed later but we can make a conditional ACK obviously 21.34.34 dazo: what's your take? 21.34.42 andj 21.34.55 indeed, a conditional ack is possible dazo 21.35.57 I understand disabling lzo by default is challenging .... however, I probably lean towards acking this one - then take a discussion around a "lets re-enable lzo by default again" thread I'm also thinking that this only impacts builders, not end users .... so packagers needs to add --enable-lzo in their build scripts/specfiles/etc 21.36.28 andj 21.36.33 yeah, you want all openvpn clients to be reasonably compatible mattock 21.36.35 the code looks less clean than usual... does it try to support lzo 1.x? andj 21.36.48 and enabling lzo is the "sane default" dazo 21.37.10 it is the sane default, if you have lzo available ... mattock 21.37.52 so, do we need lzo 1.x support? dazo 21.37.59 nope andj 21.38.01 no idea mattock 21.38.17 ok, ACK with two conditions? dazo 21.38.17 where do you see that, mattock ? mattock 21.38.45 e.g. "AC_MSG_ERROR([lzo1x.h is missing I assume that's lzo 1 header file 21.38.56 andj 21.38.59 It checks for both 1.x and 2.x I think they're both compatible 21.39.18 dazo 21.39.32 $ rpm -qf /usr/include/lzo/lzo1x.h lzo-devel-2.03-3.fc12.x86_64 21.39.33 andj 21.39.36 and having a little bit of extra code in the build system won't hurt much dazo 21.39.43 it's a header file which is a part of lzo2 mattock 21.39.54 ok, let's leave it in then dazo 21.40.17 I think it is algorithm related, not version related mattock 21.40.29 so ACK and "discuss if LZO should be enabled by default"? and maybe also discuss the lzo1x thing while we're at it? 21.40.44 dazo 21.40.48 back to the discussion ... it's more a pragmatic discussion .... however, if autotools could detect if lzo is available, and then enable it automatically - that would probably be cleaner mattock 21.40.49 on the mailing list andj 21.41.07 dazo: disagree there, since you want a predictable build mattock ok 21.41.13 mattock 21.41.32 yeah, I think that predictability was one of Alon's points dazo 21.41.46 mattock: lzo1x.h is used in the current code base andj 21.41.57 but then make it predictably lzo-enabled mattock 21.42.09 so that the build does not autodetect stuff and create binaries which may or may not have certain features andj 21.42.16 since that's what everyone uses anyway mattock 21.42.42 ACK and fix later, discuss on ml unless there are any objections 21.42.51 dazo 21.42.55 okay, I'm don't need to battle this one here ... and agree, ACK now and discuss on ML andj 21.43.24 agreed dazo 21.43.53 (the ML will reach Alon too, so he can be involved too) mattock 21.44.08 40/52 again, rather pedantic 21.44.44 but I like it... ssl-type is a bit vague 21.45.02 crypto-library is better 21.45.12 andj 21.47.14 ack with a caveat: 0.9.6 has got to go 21.47.24 mattock 21.47.44 ok, good point, I'll add that to the notes dazo 21.47.46 and that will go ... I think that's another patch somewhere, where we really kick out that part (if not, let's make configure test for openssl version) 21.48.04 mattock 21.48.15 43/52 andj 21.49.05 why???? mattock 21.49.53 hmm, a pattern is emerging... not sure about "why" 21.49.58 dazo: any clues? 21.50.10 if not, we can ask on the ml 21.50.14 dazo 21.50.15 I think it is to clarify that config-msvc.h is Visual Studio related, and much more statically ... while config.h is completely auto-generated mattock 21.50.39 hmm, that makes sense dazo 21.50.53 so config-msvc.h will only be used by MSVC ... while the autotools makes use of config.h andj 21.51.02 why did he move it to every file individually? mattock 21.51.30 yeah, that's a lot of repetition dazo 21.51.36 the idea is to get completely rid of syshead.h in the end ... as that should be created by autotools ... and if not, in config-msvc.h mattock 21.51.58 is there any solution that would not duplicate the code? andj 21.52.22 aha, ok dazo 21.52.38 to have a simple syshead.h which does that #ifdef magic with config.h vs config-msvc.h mattock 21.53.01 dazo: ACK? dazo 21.53.05 which is really ugly ... and makes people do crazy stuff with syshead.h again ... like what we have in syshead.h yeah, it's an ACK from my side ... it's code duplication ... but then you could also argue that #include <stdio.h> etc,etc is also code duplication, but we accept that 21.53.37 mattock 21.53.54 any notes you'd like to add? for future reference 21.54.13 dazo 21.54.20 nope, I'm fine with it how it is mattock 21.54.22 ok 44/52 needs code ack 21.54.43 dazo 21.54.48 having that said, it took me a few rounds of reading this patch and arguing with myself before I ended on this opinion this compat stuff is kind of clever ... and he took it a step further than what I'd expect 21.55.47 it reminds a little bit on how glibc is built up 21.56.00 but basically, each file in the compat/ dir is for each compat function .... and all is put into a static library which the linker uses to pull in the needed functions 21.56.44 the linker doesn't take everything in the library, just the stuff it needs to complete the linking 21.56.58 (and of course, there's these HAVE_$funcname macros in each compat file, which includes the code at build time) 21.57.37 andj 21.57.54 cool dazo 21.58.33 it makes it easier to expand and and read the code ... ls -l compat/ ... and you know which compat functions we have implemented mattock 21.58.33 dazo: is that an ACK? dazo 21.58.40 ACK from me mattock 21.58.54 45/52 dazo 22.00.17 here you actually see how gettimeofday() gets implemented as a compat function .... and it cleans up a lot of the code too 22.00.57 I'm not sure the side-effect of letting mingw use it's own internal gettimeofday() ... Alon asked people for some testing of different implementations, but I think he figured out it didn't matter much in regards to call duration 22.02.35 mattock 22.03.26 ah, reduces #ifdefs, nice dazo 22.03.40 it really does mattock 22.03.47 makes sense dazo 22.04.07 it's an ACK from me on 45/52 mattock 22.04.10 ok 48/52 needs a code-ACK 22.04.37 andj 22.06.01 I've never liked files called misc.c mattock 22.06.38 me neither andj 22.06.56 These last ones are a quite massive and I need a break before bed 22.07.03 so I'd like to postpone them a little bit 22.07.12 dazo 22.07.42 yeah, I hoped we could manage the last ones ... but I feel my head needs to relax soon ... this one needs more careful review mattock 22.08.04 let's review and ACK the last two on the ml andj 22.08.13 sounds like a plan mattock 22.08.16 then move on to the other patchsets later (next week?) or maybe ACK them on ml, if they're trivial enough 22.08.27 dazo 22.08.28 yeah ... that makes sense mattock 22.08.47 I can take a look at the tap-windows patchset on the ml and easy-rsa 2/4 and 4/4 only need a quick code-ack 22.09.07 dazo 22.09.18 I'll get started sometime very soonish to apply all these patches too ... its just these two last ones lacking ACKs now of this block mattock 22.10.01 and we can discuss this also on the ml: "Move official openvpn project repositories into github" from Alon 22.10.04 although we did discuss that a bit 22.10.14 dazo: what kind of summary do you want? 22.10.36 dazo 22.11.22 patch name, acker plus URL to gmane? mattock 22.11.28 ok, sounds good to me dazo 22.11.54 shouldn't be too hard, I hope mattock 22.12.09 I might even add some quotes to show how/why each patch was acked anyways, that's something for tomorrow 22.12.21 nice meeting! 22.12.25 I'll take care of the summary tomorrow 22.12.34 dazo 22.12.41 thx a lot! And thanks a lot to you too, andj, helping reviewing all this 22.12.54 mattock 22.12.59 second really major patchset to get merged! dazo 22.13.08 yeah mattock 22.13.10 I wonder who was the author of the first one good night! 22.13.27 dazo 22.13.31 should be easy to figure out James, it seems like ... well, at least as far back as my history goes 22.14.11 (to the beginning of the BETA21 SVN branch) 22.14.25 andj 22.21.47 yeah, thanks guys and btw: I sort of like github, my 2c
