cc: d...@cxf as they are good questions that others might have.... On Thu June 18 2009 4:49:39 am Alessio Soldano wrote: > Hi Dan, > I've few questions regarding the commitership and the way the project > contribution is organized: > - should I get an email when my account is properly set? I've just tried > committing to svn but I'm not allowed. Perhaps I just need to wait ;-)
Need to wait. They process account creation requests once a week or so. You should get an email with details when that happens. > - do you have a standard procedure for validating changes before commit? > Asking as running the whole testsuite, including the systests, is *really* > time consuming. Do you have some kind of smoke test? The systests kind of are the smoke test. :-) This is actually an area where using git has been saving me a bunch of time. I used to run the full test suite 4 or 5 times a day as I was committing to svn 4 or 5 times a day. With git, I now commit things to my local git branch 4 or 5 times a day with just running localized unit tests or specific system tests. Then, I run the full test suite when I have all of the things "done" and if it passes, then "git svn dcommit" the whole batch. With git- svn, each commit I do locally turns into a svn commit, but they all occur at once. That is why you'll see 4 or 5 commits from me in the period of about 30 seconds. That's git doing its thing. For the most part, definitely run the unit tests in the areas you are touching and probably the jaxws module. Beyond that, it depends on what you are doing. If you are touching the code generators, it's DEFINITELY good to do a "mvn clean ; mvn -Pnochecks" type thing to make sure all the generated code will still compile and work correctly. That said, if you do break things (it happens, even to me :-), hudson will usually catch it fairly quickly. http://hudson.zones.apache.org/hudson/view/CXF/ > - how do you handle merge of changes from trunk to the supported fix > branches? everybody merges his stuff as soon as the fix to the trunk is > committed, or do you prefer batch merges? In general, we use the svnmerge.py script (google it) to merge from tunk -> branches. That way, what is merged and is blocked gets recorded. There are two options for getting the fixes on the branch: 1) Use svnmerge.py yourself and merge it. This is the fastest way to get it onto the fixes branch and it would then be guaranteed to make it into the nightly deploys. 2) Wait a couple days and I'll do it. Once or twice a week, I run the "DoMerges" program in trunk/bin which walks me through all the commits that haven't been merged and anything that is a bug fix, I'll merge. > Besides that, is every bug fix > supposed to be merged to all the fix branches while new features goes to > trunk only? Something like that. SOME new features do get pulled back into the fixes branches if there is some demand and it doesn't really affect any existing functionality. For example, when we added the continuation support, that got pulled back into all the branches as it made things work MUCH better in ESB's such as ServiceMix that were using some of the older versions. > Sorry for bothering for this kind of things, just wanted to be sure things > are done the way you use to. Not a bother at all. Good questions. Also, if you have ideas how to streamline things even more, please propose them. -- Daniel Kulp [email protected] http://www.dankulp.com/blog
