67 lines
5.5 KiB
HTML
67 lines
5.5 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 179{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, May 9, 2006</h3>
|
|
<div class="irclog">
|
|
<p>16:31 < jrandom> 0) hi</p>
|
|
<p>16:31 < jrandom> 1) Net status and 0.6.1.18</p>
|
|
<p>16:31 < jrandom> 2) baz</p>
|
|
<p>16:31 < jrandom> 3) ???</p>
|
|
<p>16:31 < jrandom> 0) hi</p>
|
|
<p>16:31 * jrandom waves</p>
|
|
<p>16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html</p>
|
|
<p>16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18</p>
|
|
<p>16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general</p>
|
|
<p>16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet</p>
|
|
<p>16:33 <+Complication> Only the beginning too, of course</p>
|
|
<p>16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded</p>
|
|
<p>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</p>
|
|
<p>16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction</p>
|
|
<p>16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough</p>
|
|
<p>16:38 < tmp> *sigh* </p>
|
|
<p>16:38 * tmp dreams of IRC stability.</p>
|
|
<p>16:39 < jrandom> aye, on all fronts ;)</p>
|
|
<p>16:39 <+fox> <roderick_spod1> Roderick dreams of big tits.</p>
|
|
<p>16:39 < jrandom> (this is why we can filter the meeting logs... ;)</p>
|
|
<p>16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18?</p>
|
|
<p>16:41 < jrandom> if not, lets hop on over to 2) </p>
|
|
<p>16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support</p>
|
|
<p>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</p>
|
|
<p>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.</p>
|
|
<p>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)</p>
|
|
<p>16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ???</p>
|
|
<p>16:47 < jrandom> anyone have anything else to bring up for the meeting?</p>
|
|
<p>16:48 < cervantes> just to say "nice one bar" for his cool donation </p>
|
|
<p>16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB...</p>
|
|
<p>16:48 * Complication seconds that</p>
|
|
<p>16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March...</p>
|
|
<p>16:49 < cervantes> must have missed that amongst the odci.gov rants</p>
|
|
<p>16:50 < tmp> What on earth are you doing on that side roderick_spod?</p>
|
|
<p>16:50 < jrandom> aye Complication </p>
|
|
<p>16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug?</p>
|
|
<p>16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information</p>
|
|
<p>16:52 < arse> do you guys think the network periodicity is gonna subside</p>
|
|
<p>16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever</p>
|
|
<p>16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently...</p>
|
|
<p>16:52 < jrandom> arse: yes</p>
|
|
<p>16:52 <+Complication> (and partly because the watchdog lacks teeth)</p>
|
|
<p>16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there</p>
|
|
<p>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</p>
|
|
<p>16:55 < jrandom> erm, wait, no, thats not true</p>
|
|
<p>16:56 < jrandom> never mind me. yeah, it just adds a small variation</p>
|
|
<p>16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently</p>
|
|
<p>16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC?</p>
|
|
<p>16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind?</p>
|
|
<p>16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers</p>
|
|
<p>16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect</p>
|
|
<p>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</p>
|
|
<p>17:01 <+Complication> I'll try to keep it reasonable, then :)</p>
|
|
<p>17:01 < jrandom> heh cool, thanks Complication </p>
|
|
<p>17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting?</p>
|
|
<p>17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :)</p>
|
|
<p>17:05 < jrandom> w3rd Complication </p>
|
|
<p><i>offtopic messages snipped</i></p>
|
|
<p>17:08 < jrandom> ok, if there's nothing else...</p>
|
|
<p>17:08 * jrandom winds up</p>
|
|
<p>17:09 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |