db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject backporting changes to branches
Date Mon, 22 Oct 2007 20:18:08 GMT
Remember that the point of the branch is to provide a stable always 
working set of code that anyone can take and make either a public
release of or expect that a private release will work.  So only bug
fixes should go in, and when I act as a committer I usually exercise 
more caution when backporting
a fix than I might for a trunk check in.

I usually first will check in a change to the trunk and then let it
sit for a few days before putting it into the branch.  This means that
the community gets a chance to see the change, the change gets tested
against a wide variety of platforms that I may not have access to (many
of these test runs are available to everyone to browse from the derby
website), and I usually run at least one full set of tests with the
change against the branch that I am backporting to.  Then after a few 
days I know at least in trunk no new bugs have been found across all the 
various platforms and go ahead with the back port if appropriate.  This 
is just what I usually do, not the rule.  It is of course up to each
committer to use their experience and judgement to determine what makes
sense.

I still get surprised by the kinds of problems that
our tests find with a change that looks straight forward to me on code
review.

Mime
View raw message