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