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
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
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
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
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
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
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]
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