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.