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 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 offtopic messages snipped 17:08 < jrandom> ok, if there's nothing else... 17:08 * jrandom winds up 17:09 * jrandom *baf*s the meeting closed