Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Sat, Oct 19, 2013 at 12:46:33PM +0100, Ximin Luo wrote:
> On 19/10/13 06:31, David Fifield wrote:
> > On Mon, Oct 14, 2013 at 09:14:25PM +0100, Ximin Luo wrote:
> >> Specific remaining tasks:
> >>
> >> - merge #9349, #6810, #9974
> >> - push #7167 to an official tpo repo
> >> - do #9976, and #7167#comment:42 might require an obfsproxy fix
> > 
> > I agree with this, except that I don't think #9974 (facilitator
> > packaging) and #9976 (general argument passing to registration helpers)
> > are necessary for this deliverable. They are nice and I want them, but
> > in terms of this deliverable I would prioritize #9349 (facilitator
> > transport support) and #7167 (obfsâflash composition) first.
> > 
> > Would you hate me if I suggest not merging #6810 (client code
> > reorganization) until after we build at least one bundle? It's lower
> > risk to go with the organization we know works, especially given that we
> > are changing other things within the bundle.
> 
> Strictly speaking, I *would* consider them part of the deliverable,
> from the view of software quality. Not having them, would be a
> "minimal outcome" IMO. If we don't consider it part of this
> deliverable, which deliverable *are* we supposed to consider it part
> of? These arguments could be made at any time. 

Don't get me wrong--I think these things are valuable and I want to do
them right after building a test PT TBB. Those tickets aren't part of
any deliverable, but they don't have to be part of a deliverable to be
worth doing.

It's not that I'm trying to neglect unglamorous development--I'm really
not. This is how I see it: As a software engineer, I am always trying to
reduce risk. Refactoring code reduces risk in the long term but
increases risk in the short term. Sticking with our old busted
duplicated code is risky in the long term, but very predictable in the
short term. We've already done a lot to destablize the code (just by
adding new features), so if possible I prefer not to further destablize
it before trying to build bundles. The risk associated with refactoring
is one I think can be safely deferred for a couple of weeks.

Does it at least come across that there is some principled reasoning
behind my recommendations?

I'm fully with you on doing code quality improvements before WebRTC and
transport composition.

David Fifield
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev