[tor-talk] torsocks is broken and unmaintained

[Matthew Finkel]

On 11/03/2012 08:38 PM, Nick Mathewson wrote:
> On Fri, Nov 2, 2012 at 11:10 PM, Matthew Finkel <matthew.finkel at gmail.com>wrote:
> 
>> On 11/02/2012 07:36 PM, Jacob Appelbaum wrote:
>>> Nick Mathewson:
>>>> On Fri, Nov 2, 2012 at 1:34 PM, adrelanos <adrelanos at riseup.net> wrote:
>>>>>
>>>>>
>>>>> Could you blog it please?
>>>>
>>>>
>>>> I'd like to see more discussion from more people here first, and see
>>>> whether somebody steps up to say, "Yeah, I can maintain that" here, or
>>>> whether somebody else who knows more than me about the issues has
>> something
>>>> to say.  Otherwise I don't know whether to write a "looking for
>> maintainer"
>>>> post, a "who wants to fork" post, a "don't use Torsocks, use XYZZY"
>> post,
>>>> or what.
>>>>
>>>
>>> If Robert wants someone to maintain it, I'd be happy to do so. I had
>>> wanted to extend it to do some various things anyway. I think it would
>>> be a suitable base for a bunch of things I'd like to do in the next year.
>>>
>>> All the best,
>>> Jake
>>>
>>
>> I saw this thread earlier but didn't have a chance to reply. I was
>> thinking about volunteering to patch it up and maintain it if no one
>> else wanted to take it on, also, but if you want to take the lead on it
>> then I'm more than happy to help you where ever possible...assuming this
>> is the direction that's decided upon.
>>
> 
> Okay, sounds like we've got some enthusiasm.  Let's get started.  I
> volunteer to review commits and if people ask me to, and suggest that
> asking me to review stuff for a while might be a smart idea.  I just gave
> myself commit access to the git at git-rw.torproject.org repo too, in case
> that helps.  I am not planning to be a primary author here.

Thanks for adding one more thing to your plate! I know Jake can handle
this but the more eyes we have looking at these initial changes the
better it'll be.

> 
> Given the amount of people asking us to apply and/or warning us that we
> mustn't apply particular patches, I'm going to suggest the following
> principles for a while:
>   * LET'S START MINIMAL.  Let's stick to doing only the very major bugfixes
> and obvious fixes for at least the next release or two, so that something
> usable comes out.

Agreed. To be honest, I haven't really looked at the code too much, so
I'll start diving into that in a bit. (If there isn't one already...I
haven't checked) Can we get a trac component added so we can track
progress and such?

>   * NO ARCHITECTURAL ASTRONAUTICS. I'm always tempted when I come to a
> codebase for the first time to refactor the heck out of it.  Let's avoid
> doing that till we have a little experience with this codebase.  There
> isn't all that much here: let's

Yes...let's! :)

Was there supposed to be more to that sentence?

>   * LOVE MEANS GET TESTED. If at all possible, we should make this codebase
> easier to test (right now it wants you to install before testing), and
> improve the coverage of the tests so that (if as people suspect) we're
> likely to break things on one platform when we fix them on another, we can
> at least find out fast whether a patch works everywhere.
> 

Certainly sounds like a good idea. I'm going to have to familiarize
myself with some of the other *nix platforms it does/should support.
Just looking through the current issues on google code, for example, I
don't know the internals of OSX well enough *yet* to know if [1] is even
possible. But once we've compiled a list of all the current critical
patches, Debian and others (assuming such a list doesn't exist already),
then we start applying, testing, revising, etc. :)

[1] https://code.google.com/p/torsocks/issues/detail?id=41

- Matt