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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
