forked from I2P_Developers/i2p.www
206 lines
16 KiB
Plaintext
206 lines
16 KiB
Plaintext
20:04:39 <str4d> Yo
|
|
20:04:44 <str4d> It's meeting time
|
|
20:06:47 <str4d> zzz, psi, kytv, Meeh, dg
|
|
20:07:30 <psi> it is?
|
|
20:07:39 <psi> ah tuesday
|
|
20:09:03 <zzz> present
|
|
20:09:48 <orignal> meeting?
|
|
20:10:11 <str4d> orignal: discussing Java I2P's todo list
|
|
20:10:35 <str4d> While we wait for others to show up: http://trac.i2p2.i2p/wiki/Roadmaps/1.0
|
|
20:10:41 <kytv> Present as well, though I'm usually useless when it comes to these things.
|
|
20:11:37 <str4d> I have adjusted the Gantt chart on the page above (that I set up for the 0.9.13-0.9.16 dev cycle) to show what I think we did.
|
|
20:13:30 <zzz> interesting
|
|
20:14:06 <zzz> multiple dests per tunnel <-- hasn't happened
|
|
20:14:22 <str4d> Hasn't? Okay, my bad.
|
|
20:14:27 <zzz> findbugs pass <-- has happened, but can always do it again
|
|
20:14:56 <str4d> Multi-sessions per I2CP - that hasn't happened either *derp*
|
|
20:14:56 * str4d fixes
|
|
20:15:48 <zzz> wow, we had a good year (imho)
|
|
20:16:38 <eche|on> yes, we had
|
|
20:17:14 <str4d> zzz: yeah, I called it part of the audit prep specifically, but you are right.
|
|
20:17:39 <zzz> investigate new DH <---- I would say only half done, w.r.t NTCP2 anyway
|
|
20:20:26 <str4d> Gantt doesn't easily show half-done :P
|
|
20:20:34 <str4d> Reload page, fixes
|
|
20:21:36 <str4d> Okay, so that is what we got done last cycle.
|
|
20:21:36 <zzz> not done then
|
|
20:23:45 <str4d> The purpose of this meeting is to start planning what is to be done next cycle.
|
|
20:23:46 <zzz> I would like to reiterate that a 3-5 release planning cycle seems to be very helpful in focusing our minds and our resources
|
|
20:23:47 <str4d> (When I update the Gantt chart, I will leave the half-done ones there and push them forward)
|
|
20:23:47 <str4d> At the previous meeting I asked attendees to come up with a few points each of things they want to see done on I2P, and around I2P
|
|
20:23:47 <str4d> Please can we paste those now?
|
|
20:24:21 <str4d> +1
|
|
20:24:36 <str4d> And now we have evidence for it!
|
|
20:26:15 <zzz> without getting into what's more important than what, I think almost everything that's shown and unfinished on the gantt chart is still important
|
|
20:27:01 <str4d> I agree.
|
|
20:27:07 <str4d> I still want to see what ideas people came up with over the last week, if any.
|
|
20:27:45 <str4d> Here's mine: http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/
|
|
20:27:46 <iRelay> Title: Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (at pastethis.i2p)
|
|
20:28:07 <eche|on> I am out of options, I do see to get I2P out, with the help of bote android, i2p messenger is a option, a XMPP server, and syndie. Sorry, I still see syndie important.
|
|
20:28:27 <str4d> eche|on: great, thanks!
|
|
20:28:43 <str4d> Keep 'em coming :)
|
|
20:28:53 <eche|on> and with the android app there come restricted routes
|
|
20:28:54 <zzz> my list of new things: solving the red hat ECDSA problem, migrating to EdDSA, Jetty 9 / Java 7, expand the Vuze userbase, and more marketing / outreach / partnerships / embedding
|
|
20:29:36 <str4d> For logging perpetuity, I will write my ideas here too:
|
|
20:30:11 <str4d> Todo in I2P: Routerconsole UX analysis and redesign; Take ideas from Tor's HS 2.0 design and apply to I2P Destinations; Bandwidth scheduling. Todo around I2P: Website theme improvements; Implement I2P-Bote fetching relays; Research
|
|
20:30:23 <zzz> another one: orchid: fix it or kill it
|
|
20:30:32 <str4d> +100
|
|
20:31:13 <kytv> WRT the RedHat/Gentoo ECDSDA problem, maybe we could/should display a message in the sidebar (or logs) with a download link. Or maybe ask the user if 'we' should download it into ./lib
|
|
20:31:35 <zzz> another one: test improvements, test hardware, windows testing
|
|
20:31:58 <str4d> kytv: nice ideas (but discussing them can wait for another meeting :)
|
|
20:32:03 <zzz> another one: spend more money
|
|
20:32:36 <zzz> another one: China
|
|
20:32:58 <str4d> Between these ideas and the not-completed list on the page above, we have a good pool of potential projects.
|
|
20:33:34 <str4d> My goal is to get these projects tidied up, formalized and published on the website's todo page
|
|
20:34:11 <str4d> Having poked around other projects' todo pages, this is the format I am proposing:
|
|
20:34:11 <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/
|
|
20:34:12 <iRelay> Title: Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (at pastethis.i2p)
|
|
20:34:54 <eche|on> nice idea
|
|
20:35:10 <kytv> Ditto on Orchid
|
|
20:35:10 <kytv> My main "TODO around I2P" is with regards to testing. Not automated testing with software, per se, but any of our services going live without any sort of testing...just [poof], "it's live...dunno if it works though."
|
|
20:35:12 <kytv> In I2P: Making the Installer install to the user directory in Windows to avoid any sort of permissions problems. It should be easy, but I don't know how.
|
|
20:35:16 <kytv> Chrome did that (maybe still does it?)
|
|
20:35:41 <str4d> My ideal end result: users can go to the todo page and find a list of all the ideas we have for projects in and around I2P.
|
|
20:36:11 <zzz> another one: GSoC
|
|
20:36:14 <str4d> There will be a tag cloud up the top that they can click on to filter projects that require certain skils
|
|
20:36:17 <str4d> skills
|
|
20:36:21 <zzz> another one: summertime meetup
|
|
20:37:54 <zzz> another one: GNS investigation 2nd pass?
|
|
20:38:28 <str4d> mmm
|
|
20:38:54 <zzz> or maybe, just another discussion w/ those guys will do
|
|
20:39:09 <str4d> Right now, I am going to cull from the Gantt the tasks we have completed.
|
|
20:39:27 <zzz> can you save it and start a new one?
|
|
20:39:29 <str4d> zzz: which of the bottom few have been completed (SSU replay detection etc.)?
|
|
20:39:38 <str4d> Sure, I can.
|
|
20:39:49 <zzz> it's kinda nice to show that we actually accomplish things
|
|
20:40:19 <eche|on> zzz: most of the stuff was done by you IMHO
|
|
20:40:35 <EinMByte> id I miss the meeting?
|
|
20:40:37 <zzz> I think I've reported everything that was on the wrong side of completed or not
|
|
20:42:39 <str4d> New chart up
|
|
20:43:55 <str4d> zzz: which of the three down the bottom should be pushed forward? I think client locking is still an issue?
|
|
20:43:59 <zzz> I'd like to see much more planning and focus on the non-coding things in the next few months. Far too many things are either quite disorganized or not happening in anything approaching a disciplined or steady pace
|
|
20:44:09 <str4d> (client tunnel locking)
|
|
20:44:18 <str4d> zzz: I agree.
|
|
20:44:34 <str4d> This will IMHO be helped by working on the todo page.
|
|
20:44:56 <str4d> If we can explain the non-coding projects in a way that newcomers can understand and do, it also helps us.
|
|
20:44:59 <zzz> not 100% sure atm what that client locking item is, but i think it's still unfinished
|
|
20:45:08 <str4d> (Likewise for coding projects)
|
|
20:45:32 <zzz> yup
|
|
20:45:53 * str4d pushes streaming improvements forward too
|
|
20:46:03 <str4d> Can I cut SSU session replay detection then?
|
|
20:46:04 <dg> Do you mean the duplicate issues?
|
|
20:46:18 <dg> The way we'd get tunnels that don't unregister from I2PTunnel, and won't allow new ones? That sort of thing?
|
|
20:46:30 <zzz> str4d, I'll have to get back to you re: SSU replay, not sure atm
|
|
20:46:45 <dg> I'd like to see less tunnel death rather than throughput
|
|
20:46:59 <str4d> dg: that might be it. There is also the separate issue of the I2PTunnel startup locking the UI
|
|
20:47:29 <zzz> put 'tunnel death' on there as a new item, why not
|
|
20:48:01 <dg> str4d: Forgot about that!
|
|
20:48:03 <str4d> k
|
|
20:48:39 <zzz> I think the locking thing I have some unchecked in code for, been dragging along for 18 months or so, but still not right
|
|
20:48:40 <str4d> Next: look through the ideas above. Which ones should go on *our* 6-month sheet (ie. which should I add to Gantt)?
|
|
20:50:16 <psi> EinMByte: meeting in progress
|
|
20:50:21 <psi> (no)
|
|
20:51:51 <zzz> I suggest everything go on there for now, then we later talk about priorities, or let the gantt dependencies tell us what to do next?
|
|
20:52:52 <str4d> mmk
|
|
20:53:04 * str4d is pulling out the list from above and tidying it up now
|
|
20:53:08 <EinMByte> psi: oh great.
|
|
20:54:08 <psi> potential item: benchmark tunnel throughput and message drop rates
|
|
20:54:26 <str4d> EinMByte: do you have any ideas for our todo list?
|
|
20:55:15 <EinMByte> NTCP2, possibly. Although it would be long term
|
|
20:56:39 <str4d> EinMByte: for reference: http://trac.i2p2.i2p/wiki/Roadmaps/1.0
|
|
20:56:53 <EinMByte> thanks
|
|
20:57:04 <EinMByte> (was about to ask)
|
|
21:00:23 <str4d> Here is the list of everyone's ideas:
|
|
21:00:24 <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/
|
|
21:00:25 <iRelay> Title: Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (at pastethis.i2p)
|
|
21:01:01 <str4d> Nearly all of these can be turned into projects for the website todo page.
|
|
21:01:36 <str4d> Next discussion topic: which of these (and the ones on the Gantt currently) are more important for us to do in the next six months?
|
|
21:02:48 <psi> restricted routes is probably the most important item IMO
|
|
21:02:50 <EinMByte> with respect to syndie, maybe: I was working on this plugin - no time now though). This might be one of the things that can (?) bring more attention to syndie.
|
|
21:03:20 <dg> str4d: Tunnel death is absent and I feel that's quite important
|
|
21:03:37 <EinMByte> If anyone is interested in doing firefox / icedove plugin development: you know what to do
|
|
21:03:37 <str4d> dg: it's there (tunnel thread locking)
|
|
21:03:41 <str4d> I thought that's what it was
|
|
21:03:49 <dg> oh, sorry str4d, I meant when connections are abruptly terminated
|
|
21:03:54 <dg> my bad
|
|
21:04:04 <str4d> Ah, k
|
|
21:04:55 <EinMByte> psi: I agree restricted routes are important. But I also think we should realize that it will take quite some time to implement
|
|
21:05:21 <EinMByte> (not sure how much of the design / concept has been done)
|
|
21:05:35 <dg> In I2P: restricted routes, RedHat's ECDSA issues, Tor's HS 2.0, then the rest. Around I2P: Vuze userbase, GSoC, research, benchmark, then the rest.
|
|
21:06:04 <dg> I agree with EinMByte.. the router console redesign is important but that could take an indeterminate amount of time.
|
|
21:07:15 <EinMByte> str4d: one more thing, possibly. I know some reasearchers who have developed a new concept for a DWSE (distributed web search engine), they might be interested in developing this as an I2P application
|
|
21:07:42 <str4d> EinMByte: nice!
|
|
21:07:49 <EinMByte> Since most DWSEs right now don't really work well, it would be very interesting to have this IMHO
|
|
21:08:01 <zzz> no, by 'tunnel death' I meant 3-minute tunnel breakage, the Vuze guy's datagram test, etc. Distinct from local i2ptunnel locking issues.
|
|
21:08:07 <EinMByte> It's also something I would consider implementing
|
|
21:08:20 <dg> I wasn't thinking of precisely 3-minute but that was included.
|
|
21:08:34 <EinMByte> (with help, hopefully)
|
|
21:09:03 <str4d> k, reload Gantt page
|
|
21:10:34 <EinMByte> str4d: anyway don't count on this too much, it depends on whether I2P users are actually interested in something like this.
|
|
21:11:14 <EinMByte> Also, I'm not sure about the GNS stuff. In any case it shouldn't have a high priority.
|
|
21:11:56 <str4d> Updated new ideas paste: http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/
|
|
21:11:57 <iRelay> Title: Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (at pastethis.i2p)
|
|
21:12:35 <zzz> i'd say 4 broad categories are the highest importance: 1) near-term crypto migration continuing (addressbook, muiltidest, etc) 2) longer-term crypto planning/research (DH, LS2, NTCP2) 3) all things testing 4) all things non-coding
|
|
21:13:48 <EinMByte> zzz: is that in order of importance?
|
|
21:14:05 <str4d> ECDSA issues fall into the first category; Tor HS 2.0 falls into the second category.
|
|
21:14:21 <zzz> no. roughly equal importance
|
|
21:14:44 <str4d> So the only item not represented in those categories is restricted routes
|
|
21:15:28 <jenkins@kyirc> Starting build #556 for job i2pd (previous build: SUCCESS)
|
|
21:15:30 <jenkins@kyirc> Project i2pd build #556: SUCCESS in 8.2 sec: http://jenkins.killyourtv.i2p/job/i2pd/556/
|
|
21:15:31 <jenkins@kyirc> * orignal: eliminated NTCPServerConnection
|
|
21:15:32 <jenkins@kyirc> * orignal: moved NTCP client code to Transports
|
|
21:16:34 <EinMByte> maybe NTCP2 is not *that* important
|
|
21:16:50 <zzz> and the reason I grouped them like that and say equal priority is that it's probably 4 separate groups of people for those 4 categories that could each make progress
|
|
21:17:08 <EinMByte> or, at least before we can start propertly on the NTCP2 we need to do a lot of research, also answer a few very important questions
|
|
21:17:33 <jenkins@kyirc> Project i2pd (Linux x86) build #33: SUCCESS in 1 min 47 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/
|
|
21:17:44 <EinMByte> zzz: indeed
|
|
21:17:51 <JekabsR> it is interesting that i2p network tends to bring all fast routers together
|
|
21:17:58 <jenkins@kyirc> Starting build #33 for job i2pd (Linux x64)
|
|
21:18:03 <zzz> right. "NTCP2" is just shorthand for a bunch of stuff that may or may not actually result in something called "NTCP2"
|
|
21:18:34 <JekabsR> and they do not prefer slow routers
|
|
21:18:40 <EinMByte> Yes. In any case if we change the transport layers it's extremely important not to make mistakes, as that would probably break I2P entirely.
|
|
21:19:19 <psi> JekabsR: slower routers are still used just not as much
|
|
21:19:43 <jenkins@kyirc> Project i2pd (Linux x64) build #33: SUCCESS in 1 min 52 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/
|
|
21:20:05 <EinMByte> zzz: if 2 is "research", then you are right though
|
|
21:20:33 <EinMByte> it can be done simultaneously
|
|
21:21:52 * str4d is reworking the Gantt into these four categories (plus an Other category)
|
|
21:22:12 <JekabsR> but there is a problem - client like destinations rarely get fast router connections
|
|
21:22:40 <eche|on> no?
|
|
21:22:46 <psi> JekabsR: not entirely sure if that is accurate
|
|
21:23:46 <zzz> str4d, did we forget Android, or is that a separate roadmap?
|
|
21:23:59 <str4d> zzz: we have forgotten it
|
|
21:24:01 <eche|on> JekabsR: hidden mode routers do have some issues, but other do get fast connections, as enough fast routers are available and do have free capacity
|
|
21:24:26 <str4d> Technically I2P Android falls into the "in I2P" category
|
|
21:24:35 <psi> oh another reasearch question: how much capacity does i2p actually have right now?
|
|
21:25:14 <zzz> maybe a 5th category for android makes more sense
|
|
21:25:46 <zzz> but I'm not hung up on categories. I just mentioned the 4 as a quick way to communicate what I think is important
|
|
21:25:54 <JekabsR> because they tend to create small number of really fast connections and large number of slow connections
|
|
21:26:11 <dg> [citation needed]
|
|
21:26:15 <JekabsR> my router started to drop slow tunnels
|
|
21:26:24 <str4d> zzz: I think it was a good idea
|
|
21:26:56 <str4d> Refresh Gantt page now
|
|
21:27:07 <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf
|
|
21:30:12 <eche|on> JekabsR: tunnels are dropped only on end of tunnel lifetime and if own tunnels need the capacity.
|
|
21:30:29 <str4d> If you refresh http://trac.i2p2.i2p/wiki/Roadmaps/1.0 you will now see the headings, each with a six-month bar. This gives an indication of how much time there is to fit everything in.
|
|
21:32:43 <str4d> Now that we have some ideas for the next six months, we need to start planning times.
|
|
21:33:18 <str4d> And who is going to tackle what.
|
|
21:33:52 <JekabsR> my console frequently reports that it has too many incoming connections and tunnels are partially rejected. How i2p decides which one to reject?
|
|
21:34:08 <dg> 'too many incoming connections'?
|
|
21:34:21 <dg> JekabsR: a meeting is currently ongoing, you may want to wait until it's over
|
|
21:35:00 <str4d> I would also like some volunteers to help turn the list of ideas into a working projects page on the website todo
|
|
21:35:12 <JekabsR> NTCP connections: 425. Limit: 425. Timeout: 2 min.
|
|
21:35:30 <JekabsR> UDP connections: 1149. Limit: 1275. Timeout: 4 min.
|
|
21:36:14 <JekabsR> limits are hit
|
|
21:37:42 <JekabsR> router is using 80% of CPU power
|
|
21:38:23 <str4d> Anyone?
|
|
21:39:36 <kytv> JekabsR: 1) meeting underway, you may want to wait; 2) look at http://127.0.0.1:7657/peers#help
|
|
21:41:16 <JekabsR> kytv: will check it out
|
|
21:41:44 <zzz> str4d, i think you lost everybody after an hour 45. Maybe declare victory for now and we'll make more progress at another time?
|
|
21:41:45 <str4d> Let's try some more specific questions.
|
|
21:41:52 <str4d> Or that./
|
|
21:41:55 <JekabsR> 330,0 / 342,4 KBps my current load
|
|
21:42:06 <str4d> Yah, we have definitely made good progress.
|
|
21:42:30 <JekabsR> and torrent uploads at 2 - 5kb speed :(
|
|
21:44:17 <str4d> Thanks for the discussions, everyone!
|
|
21:44:20 * str4d warms up the baffer
|
|
21:44:20 * str4d ***bafs the meeting closed
|