Let me put in a plug for feeding the fish ... EYE. Be sure, when writing commit comments, to put JIRA numbers into them, so that FISH-EYE will automatically annotate JIRA.
Which suggests an opportunity to state a few other general principles, which I will explain by telling a story. You run into a problem, or someone reports something on the user list. 1) You open a JIRA. 2) You create a test case that fails. 3) You fix the issue. 4) You commit the fix with a comment in that (a) includes the JIRA number and (b) explains what you did and why. 5) You resolve the JIRA. 6) If you think the rest of us could learn something from your travails, you send email to the dev list describing your adventures. I think we should have some workflow to organize the patch porting process a bit better, but for now you're done. On Thu, Jun 18, 2009 at 9:24 AM, Daniel Kulp<dk...@apache.org> wrote: > > 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 > dk...@apache.org > http://www.dankulp.com/blog >
