{% extends "_layout.html" %} {% block title %}I2P Development Meeting 179{% endblock %} {% block content %}

I2P dev meeting, May 9, 2006

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

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

{% endblock %}