The refactoring question seems to be a bit of thorn: > My understanding was that new committers come in and start with some feature > implement that and then slowly start looking into what more they could do > going forward. It is NOT come in and refactor the hell out of the system > because you like something to be in a specific way. I do not beleive this > will fly in any community. It is something like we now going through the > entire code base and changing all the stuff just because I like it in a > specific way. This seems ludicrous.
I think it is reasonable that a codebase that has evolved for over two years has significant opportunity for refactoring when it is opened to a host of new developers. That said, large scale refactoring *at this stage* hurts us in two ways: 1. We don't have a rich suite of unit tests. Even automatic refactoring without unit tests makes me uncomfortable. 2. Big refactoring makes it difficult for the original developers (A&P) to review patches quickly. I can understand Avinash's resistance to big refactoring, and to some extent, I agree. While I think we may need significant refactoring as the codebase moves forward (to simplify, keep it healthy and make contributions easier), perhaps we should hold off on accepting big refactorings until: a) We have a richer suite of unit tests. b) We've done an initial stable release That seems like a reasonable restriction on the refactoring story, yes ? Avinash, Prashant, Jonathan, others -- does this seem like a good strategy? Alternative ideas?
