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.
