I will certainly help. Your fourth point puzzles me. Maybe for some tests it is true, they can be separated from the code these are testing , for some it is not. Shouldn't we use that as guide? Am I seeing things to simple?
Sent from my iPhone On 22 jul. 2014, at 18:19, "Leo Simons" <lsim...@schubergphilis.com<mailto:lsim...@schubergphilis.com>> wrote: (mostly for schuberg philis internal, but CC to cloudstack as fyi in case someone is following our github) Hey folks, Just discussing with Daan. Now that we’re figuring out our plan for writing the code a bit, I think we have to reflect that in source code management. First, for reference, cloudstack community has been discussing a move to this basic model (and I hope they do it soon!) http://nvie.com/posts/a-successful-git-branching-model/ I think for our work we should incorporate something similar, and we should have more than just a “redundant refactored virtual router” feature. That will be so big a patchset it will not be reviewable for the community. See attached picture (or http://i.imgur.com/TshmUeY.png if it gets stripped). I think it says more than the words below :-) <branching.png> First, I think we need to make some effort to split “refactoring that does not change functionality” from “adding or changing functionality”. This will allow reviewers to ‘mechanically’ review refactoring changes (“yes it seems likely this code still does the same” or “I see you clicked some refactor buttons in eclipse, yes yes") and focus most brain power on the functionality (“yes I see how this is providing redundancy that matches the design”). Second, I think we need to organize the code _clearly_ along the division of labor/topics/functionality that we are finding. That is, work on the systemvm functionality itself can be seen as pretty isolated from the management server and shows up as a prereq/dependency for the matching code in the management server that invokes the new version of the systemvm. So we can a systemvm-foo feature branch and a systemvm-java feature branch. Third, I think we need to try hard to split off bits and pieces that can be submitted back upstream to apache as distinct patch sets. For example the work I’m doing to get the systemvm veewee build working in our jenkins can be isolated into its own feature/patchset so I’m doing that. I imagine something similar may be true for publicizing our marvin integration test bits and pieces, especially where we are adding existing tests for new functionality. Fourth, I’m torn on whether I like the testing experiments intermixed with the other refactor work. Obviously its the only convenient way to refactor along the test case, but given the experimental nature it will mean some kind of tricky git subtree tomfoolery or whatnot to filter out the abandoned experiments later. I guess, use a different package name please :-) In particular this means ditching/rebasing/replaying vpc-toolkit / vlc-toolkit-hugo into bits and pieces; they’re too messy and misnamed! It should be pretty feasible still right now to cherry-pick / rebase our way through. A few weeks from now it will have gotten very hard. I am probably safe to volunteer to do a lot of the work (probably getting Daan to help me) to get this set up, but getting this right is obviously always a team effort. Thoughts? Objections? Too much / too little? Alternatives? cheers, Leo
