22:04:29 <eyedeekay> Hi everybody, who all is here?
22:04:40 <eche|on> peep :-=)
22:04:46 <zlatinb> hi
22:04:48 <zzz> present
22:06:18 <eyedeekay> All right, first topic, 0.9.46, zzz take it away
22:06:52 <zzz> wrapping up about two months of work on ratchet (proposal 144)
22:07:16 <zzz> I'm about at completion of "phase 2" where it's feature-complete
22:07:32 <zzz> and will be moving into more bug fixing and testing
22:07:51 <zzz> so 46 will be where more people can test it, and perhaps we enable it by default in 47
22:08:23 <zzz> going forward I'll be turning attention to other bug fixes and topics, such as streaming (working with zlatinb)
22:08:56 <zzz> EOT from me, so perhaps others would like to say what they're working on for 46
22:09:01 <eche|on> I just did upgrade to -5 2 days ago, still works fine, the tunnel patch round robin is included, currently no big change noted
22:09:56 <zlatinb> I’ve been re-re-reading the TCP RFCs and noticing many discrepancies in our streaming and ssu implementations.  So I rewrote them.  Tickets are on trac
22:10:24 <eche|on> very very detailed reading and checking, zlatinb 
22:11:34 <eyedeekay> I've started working on revisions to the i2ptunnel UI to reduce the amount of unnecessary information we present to new users and on the periodic key rotation mechanism for i2ptunnels
22:12:19 <eyedeekay> Lots of out-of-tree stuff for me too, I want to replace the Firefox profile bundle with something that works on non-Windows platforms as well, that is shaping up quite nicely.
22:12:32 <eyedeekay> Is that all for everyone?
22:12:46 <eche|on> looks like
22:12:49 <eyedeekay> Also, does anyone have any questions?
22:13:47 <eyedeekay> So far so good. Next is misc
22:14:37 <eyedeekay> Re: git migration, the decision has been made to migrate i2p.i2p *after* the next release and not before. Other repositories may be migrated sooner on a case-by-case basis.
22:15:06 <eche|on> good
22:15:20 <eyedeekay> Registration on git.idk.i2p is open, but it requires manual approval from an admin. We are timely about it, but feel free to ping me if you're in a hurry.
22:16:46 <eyedeekay> The preferred approach is to use git with SSH at this time, except for the initial clone, which you can perform by downloading the git bundle with snark.
22:16:50 <eyedeekay> EOT
22:17:18 <eyedeekay> Any questions for me re: git migration?
22:17:31 <eche|on> any progress on trac ticket inclusion?
22:17:49 <eyedeekay> I haven't had time to work on tracboat, so no not yet.
22:17:58 <eche|on> ok
22:18:41 <zlatinb> I have 2 questions regarding the migration:
22:18:41 <zlatinb> 1. Is there a way to change the network read timeout in ssh during the git clone.  If yes, increasing it to something like 5 minutes will improve the chances of success
22:18:41 <zlatinb> 2. As trac hasn’t been very reliable, is it ok to start opening or mirroring tickets to GitLab.  Will they be looked at?
22:19:15 <eyedeekay> 1: I have been investigating this, it does not appear so but I cannot answer conclusively yet.
22:19:20 <zzz> re: 2) not by me, if you mean i2p.i2p
22:19:25 <eche|on> for 2: tracboat would be the script solution including all trac tickets into git
22:19:54 <zzz> related q: what's the plan to improve the consistently poor uptime of public-facing services run by meeh?
22:20:02 <eche|on> oh, sorry, for copy/migrating existnat tickets, new ones maybe a issue
22:20:18 <zlatinb> will ticket numbers be preserved?  If so, what happens to the tickets already opened on GL, do they need to be deleted?
22:21:21 <eyedeekay> Ticket numbers should be preserved if I can get the migration to work, duplicate tickets will need to be deleted manually when one or the other ticket is closed.
22:22:08 <zlatinb> and if for whatever reason the migration can’t work, what’s the backup plan?
22:23:12 <zzz> we haven't yet agreed to trac migration at all; I assume any of this is just experiments. I propose that trac migration be deferred until after all mtn branches (including those not on GH at all yet) are migrated to git
22:23:33 <zzz> perhaps sept. earliest
22:23:42 <eche|on> the answer to this will correlate with zzz question, currently there is no fixed plan. My idea would be keeping trac running with older tickets 
22:24:02 <eyedeekay> I don't have a way to fix trac, migrating tickets off of it is the only thing I personally can do. If I can't migrate them with tracboat, I have to do it myself. I know the gitlab side of it, I will just have to learn the trac side of it. I know gitlab seems like an obvious and appealing replacement for trac, but this is a substantial blocker.
22:24:03 <zlatinb> ok, and until a migration has been attempted are we to continue using trac?
22:24:41 <eyedeekay> Yes
22:24:51 <eche|on> ticket wise: please use trac as long until ticket migration has been done 
22:24:53 <zzz> so who is in charge of fixing meeh's services? or have we given up and are now working to replace everything he runs? If that's what we're doing, let's be explicit about it
22:25:56 <eche|on> meeh is in charge for his services. trac should be replaced by git. 
22:26:31 <zzz> which doesn't fix the systemic issues with other services such as deb repo and outproxy
22:26:31 <eche|on> the debian repository is a open point currently, I did a mirror of it, but currently need more time to look into setting it up as expected
22:27:32 <eche|on> outproxy I will not touch at all
22:27:50 <eyedeekay> I am happy to help replace meeh's deb repo, but I can't do anything for outproxy.
22:29:19 <eche|on> meeh often told us the issue is mostly the old system on old IPs he is using, with welterde changing the DNS that did change today
22:29:33 <zzz> I assume ticket migration for a particular branch X would occur only after we have moved from mtn to git for X
22:29:35 <eche|on> but currently no idea
22:30:55 <eyedeekay> zzz Yes
22:31:08 <eyedeekay> Re: ticket migration
22:31:27 <eyedeekay> That way we would not confuse people about where issues are being discussed.
22:32:21 <eyedeekay> Anything else?
22:34:22 <eyedeekay> timeout: 60s
22:36:22 <eyedeekay> **Bafs** OK thanks for coming everyone