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

[Ximin Luo]

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. 

If this is an isolated case then fine, but I don't want to see a pattern where unsexy sub-surface work is repeatedly neglected. We're not trying to capture a market so there's no need for "just good enough" tactics. That would be analogous to shoddy construction work / software engineering that looks ok and works ok until it collapses in an earthquake or gets your mass user-base auto-exploited, or in our case if someone does more work on top of flashproxy (#6810 fixes this) or wants to use a client with a different facilitator (#9976 would fix this) or wants to install a new facilitator (#9974 fixes this by greatly lowering the cost). (The last few are pretty important if we don't want a central point of failure.)

If you de-prioritise that work now to make a deadline, you must treat them with highest priority afterwards, before taking on newer features like webRTC or general PT composition. (As opposed to e.g. the previous cycle where we started with #7167, a big new feature.) Especially #6810 - I consider that to be paying off technical debt incurred from the previous cycle, so this isn't even de-prioritising, it's pushing back the correction of what should have been corrected already.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131019/d192a30c/attachment.sig>