16:31 < jrandom> 0) hi
16:31 < jrandom> 1) Net status and 0.6.1.18
16:31 < jrandom> 2) baz
16:31 < jrandom> 3) ???
16:31 < jrandom> 0) hi
16:31  * jrandom waves
16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html
16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18
16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general
16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet
16:33 <+Complication> Only the beginning too, of course
16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded
16:35 < jrandom> there are still a few big guns left to deploy on the net, but I'd like things to stabilize first before pushing out major changes
16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction
16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough
16:38 < tmp> *sigh* 
16:38  * tmp dreams of IRC stability.
16:39 < jrandom> aye, on all fronts ;)
16:39 <+fox> <roderick_spod1> Roderick dreams of big tits.
16:39 < jrandom> (this is why we can filter the meeting logs... ;)
16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18?
16:41 < jrandom> if not, lets hop on over to 2) 
16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support
16:43 < jrandom> as mentioned in the mail, gcj doesn't really seem viable on mingw atm, though we might be able to pull some tricks
16:44 < jrandom> there is an older 3.4.4/3.4.5 gcj that works on mingw, but the classpath suport in there is pretty old.
16:45 < jrandom> (and even after stripping a bunch out of hsqldb, there are still some dependencies that 3.4.5 doesn't meet.  but maybe we can hack those out too... if necessary)
16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ???
16:47 < jrandom> anyone have anything else to bring up for the meeting?
16:48 < cervantes> just to say "nice one bar" for his cool donation 
16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB...
16:48  * Complication seconds that
16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March...
16:49 < cervantes> must have missed that amongst the odci.gov rants
16:50 < tmp> What on earth are you doing on that side roderick_spod?
16:50 < jrandom> aye Complication 
16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug?
16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information
16:52 < arse> do you guys think the network periodicity is gonna subside
16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever
16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently...
16:52 < jrandom> arse: yes
16:52 <+Complication> (and partly because the watchdog lacks teeth)
16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there
16:55 < jrandom> also, the assumption they've made isn't correct, publishedTimeAgo is how long ago the router /received/ the netDb entry, not when it was signed
16:55 < jrandom> erm, wait, no, thats not true
16:56 < jrandom> never mind me.  yeah, it just adds a small variation
16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently
16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC?
16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind?
16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers
16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect
16:59 < jrandom> but yeah, adding more variation is fine.  it'd affect stat.i2p's uptime plots, but as long as it keeps things reasonable, thats cool
17:01 <+Complication> I'll try to keep it reasonable, then :)
17:01 < jrandom> heh cool, thanks Complication 
17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting?
17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :)
17:05 < jrandom> w3rd Complication 
<i>offtopic messages snipped</i>
17:08 < jrandom> ok, if there's nothing else...
17:08  * jrandom winds up
17:09  * jrandom *baf*s the meeting closed