Reunião de Desenvolvedores do I2P - 07 de abril de 2020

22:04:29 <eyedeekay> Olá, pessoal, quem está aqui? 22:04:40 <eche|on> peep :-=) 22:04:46 <zlatinb> oi 22:04:48 <zzz> presente 22:06:18 <eyedeekay> Certo, primeiro tópico, 0.9.46, zzz, a palavra é sua 22:06:52 <zzz> concluindo cerca de dois meses de trabalho no ratchet (proposal 144) 22:07:16 <zzz> estou chegando à conclusão da "fase 2", onde fica completo em funcionalidades 22:07:32 <zzz> e vou passar para mais correções de bugs e testes 22:07:51 <zzz> então a 46 será onde mais pessoas poderão testá-lo, e talvez o habilitemos por padrão na 47 22:08:23 <zzz> daqui para frente vou voltar a atenção para outras correções de bugs e tópicos, como streaming (trabalhando com o zlatinb) 22:08:56 <zzz> EOT da minha parte, então talvez outros queiram dizer no que estão trabalhando para a 46 22:09:01 <eche|on> Acabei de atualizar para -5 há 2 dias, ainda funciona bem, o patch de tunnel round robin está incluído, no momento nenhuma grande mudança observada 22:09:56 <zlatinb> Tenho relido várias vezes as RFCs do TCP e notado muitas discrepâncias nas nossas implementações de streaming e ssu. Então eu as reescrevi. Os tickets estão no trac 22:10:24 <eche|on> leitura e verificação muito, muito detalhadas, zlatinb 22:11:34 <eyedeekay> Comecei a trabalhar em revisões na UI do i2ptunnel para reduzir a quantidade de informações desnecessárias que apresentamos a novos usuários e no mecanismo de rotação periódica de chaves para i2ptunnels 22:12:19 <eyedeekay> Muitas coisas out-of-tree (fora da árvore) para mim também; quero substituir o pacote de perfil do Firefox por algo que funcione também em plataformas que não sejam Windows; isso está se encaminhando muito bem. 22:12:32 <eyedeekay> Isso é tudo para todo mundo? 22:12:46 <eche|on> parece que sim 22:12:49 <eyedeekay> Além disso, alguém tem alguma pergunta? 22:13:47 <eyedeekay> Até agora tudo certo. O próximo é assuntos diversos 22:14:37 <eyedeekay> Re: migração para git, foi tomada a decisão de migrar o i2p.i2p *após* o próximo lançamento e não antes. Outros repositórios podem ser migrados mais cedo, caso a caso. 22:15:06 <eche|on> bom 22:15:20 <eyedeekay> O cadastro em git.idk.i2p está aberto, mas requer aprovação manual de um administrador. Nós somos ágeis nisso, mas fique à vontade para me pingar se você estiver com pressa. 22:16:46 <eyedeekay> A abordagem preferida é usar git com SSH neste momento, exceto para o clone inicial, que você pode realizar baixando o git bundle com o snark. 22:16:50 <eyedeekay> EOT 22:17:18 <eyedeekay> Alguma pergunta para mim sobre a migração para git? 22:17:31 <eche|on> algum progresso na inclusão de tickets do trac? 22:17:49 <eyedeekay> Não tive tempo de trabalhar no tracboat, então não, ainda não. 22:17:58 <eche|on> ok 22:18:41 <zlatinb> Tenho 2 perguntas sobre a migração: 22:18:41 <zlatinb> 1. Há alguma forma de alterar o tempo limite de leitura de rede no ssh durante o git clone? Se sim, aumentá-lo para algo como 5 minutos melhorará as chances de sucesso 22:18:41 <zlatinb> 2. Como o trac não tem sido muito confiável, tudo bem começar a abrir ou espelhar tickets no GitLab? Eles serão analisados? 22:19:15 <eyedeekay> 1: Tenho investigado isso; não parece que sim, mas ainda não posso responder de forma conclusiva. 22:19:20 <zzz> sobre: 2) não por mim, se você estiver falando de i2p.i2p 22:19:25 <eche|on> para 2: o tracboat seria a solução em script, incluindo todos os tickets do trac no git 22:19:54 <zzz> pergunta relacionada: qual é o plano para melhorar o tempo de atividade consistentemente ruim dos serviços voltados ao público operados pelo meeh? 22:20:02 <eche|on> ah, desculpe, para copiar/migrar tickets existentes, os novos talvez sejam um problema 22:20:18 <zlatinb> os números dos tickets serão preservados? Se sim, o que acontece com os tickets já abertos no GL, eles precisam ser apagados? 22:21:21 <eyedeekay> Os números dos tickets devem ser preservados se eu conseguir fazer a migração funcionar; tickets duplicados precisarão ser apagados manualmente quando um ou outro ticket for encerrado. 22:22:08 <zlatinb> e se, por qualquer motivo, a migração não puder funcionar, qual é o plano de contingência? 22:23:12 <zzz> ainda não concordamos com a migração do trac de forma alguma; presumo que qualquer coisa disso sejam apenas experimentos. Proponho que a migração do trac seja adiada até que todos os ramos do mtn (incluindo os que ainda não estão no GH) sejam migrados para git 22:23:33 <zzz> talvez setembro, no mais cedo 22:23:42 <eche|on> a resposta a isso se correlacionará com a pergunta do zzz; no momento não há um plano fixo. Minha ideia seria manter o trac rodando com os tickets mais antigos 22:24:02 <eyedeekay> Eu não tenho como consertar o trac; migrar os tickets para fora dele é a única coisa que eu, pessoalmente, posso fazer. Se eu não puder migrá-los com o tracboat, vou ter que fazer eu mesmo. Eu conheço o lado do gitlab disso, só vou ter que aprender o lado do trac. Eu sei que o gitlab parece uma substituição óbvia e atraente para o trac, mas isso é um bloqueio substancial. 22:24:03 <zlatinb> ok, e até que uma migração seja tentada, devemos continuar usando o trac? 22:24:41 <eyedeekay> Sim 22:24:51 <eche|on> quanto a tickets: por favor, usem o trac até que a migração de tickets tenha sido feita 22:24:53 <zzz> então, quem é responsável por corrigir os serviços do meeh? ou desistimos e agora estamos trabalhando para substituir tudo o que ele opera? Se é isso que estamos fazendo, vamos ser explícitos sobre isso 22:25:56 <eche|on> meeh é responsável pelos seus serviços. o trac deve ser substituído pelo git. 22:26:31 <zzz> o que não resolve os problemas sistêmicos com outros serviços como o repositório deb e o outproxy 22:26:31 <eche|on> o repositório debian é um ponto em aberto no momento; eu fiz um espelho dele, mas agora preciso de mais tempo para ver como configurá-lo como esperado 22:27:32 <eche|on> outproxy eu não vou tocar de forma alguma 22:27:50 <eyedeekay> Estou feliz em ajudar a substituir o repositório deb do meeh, mas não posso fazer nada pelo outproxy. 22:29:19 <eche|on> o meeh frequentemente nos disse que o problema é principalmente o sistema antigo em IPs antigos que ele está usando; com o welterde alterando o DNS, isso mudou hoje 22:29:33 <zzz> presumo que a migração de tickets para um determinado ramo X ocorreria apenas depois que tivermos passado de mtn para git para X 22:29:35 <eche|on> mas, no momento, sem ideia 22:30:55 <eyedeekay> zzz Sim 22:31:08 <eyedeekay> Re: migração de tickets 22:31:27 <eyedeekay> Dessa forma, não confundiríamos as pessoas sobre onde os problemas estão sendo discutidos. 22:32:21 <eyedeekay> Mais alguma coisa? 22:34:22 <eyedeekay> tempo limite: 60s 22:36:22 <eyedeekay> **Bafs** OK, obrigado a todos por terem vindo