Re: [tor-dev] IRC meeting to discuss sponsor F progress on Wed July 31, 18:00 to 19:00 UTC in #tor-dev

2013-07-25 Thread Karsten Loesing
On 7/25/13 2:46 PM, Karsten Loesing wrote: Hi all, I'd like to schedule an IRC meeting to discuss what progress we made on sponsor F deliverables in July. Suggested time and place are: Wed July 31, 18:00 to 19:00 UTC in #tor-dev That's in 8 days from today. The time in other

[tor-dev] IRC meeting to discuss sponsor F progress on Wed July 31, 18:00 to 19:00 UTC in #tor-dev

2013-07-25 Thread Karsten Loesing
Hi all, I'd like to schedule an IRC meeting to discuss what progress we made on sponsor F deliverables in July. Suggested time and place are: Wed July 31, 18:00 to 19:00 UTC in #tor-dev That's in 8 days from today. The time in other timezones is: 11:00 in San Francisco 14:00 in Boston

Re: [tor-dev] IRC meeting to discuss sponsor F progress on Wed July 31, 18:00 to 19:00 UTC in #tor-dev

2013-07-25 Thread Runa A. Sandvik
On Thu, Jul 25, 2013 at 12:46 PM, Karsten Loesing kars...@torproject.org wrote: Hi all, I'd like to schedule an IRC meeting to discuss what progress we made on sponsor F deliverables in July. Suggested time and place are: Wed July 31, 18:00 to 19:00 UTC in #tor-dev That's in 8 days from

Re: [tor-dev] TorPylle: a Python/Scapy TOR protocol implementation

2013-07-25 Thread Damian Johnson
This part isn't actually true. We review each other's code, and don't merge stuff without reviewing it. Further, Andrea is full-time on the tor codebase, just like me. The code review slows us down a fair bit, but we do do it. My bad then. From interactions on tickets and commit history it

Re: [tor-dev] TorPylle: a Python/Scapy TOR protocol implementation

2013-07-25 Thread Brandon Wiley
On Thu, Jul 25, 2013 at 10:23 AM, Damian Johnson ata...@torproject.orgwrote: (What I'm *not* thrilled about is the idea of using an embedded interpreter for this kind of stuff, or embarking on any direction that requires us to rewrite too much of the program at once. That way, in my

Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.

2013-07-25 Thread Nikita Karetnikov
Sorry for being slow to get to your patches. No problem. I'm glad that someone is actually interested in that. An overall comment: I am unconvinced about commit messages that details obvious changes for each impacted file. Well, I agree. However, even obvious changes might be useful in the

Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.

2013-07-25 Thread Lunar
Nikita Karetnikov: Well, I agree. However, even obvious changes might be useful in the long term. The GNU Coding Standards, which I use as a guide, suggest the following: Subsequent maintainers will often search for a function name to find all the change log entries that pertain to it... [1]

Re: [tor-dev] PRELIMINARY: [PATCH 3/3] Replace 'TorDNSEL.System.Timeout' with 'System.Timeout'.

2013-07-25 Thread Nikita Karetnikov
Using `git blame` or `git log -S` or `git log -G` will actually work better than a file by file summary. If you throw in the `-M` option, it'll work accross renames, for examples. OK. But that information will be lost if we decide to change a VCS for some reason. Why not put what you wrote