Re: backporting changes to branches

[Henri van de Scheur <He...@Sun.COM>]

Just some info here, maybe not everybody is aware of this, but branch 
10.3 is also daily tested on 4 platforms. You will find references under 
http://dbtg.thresher.com/derby/test/ and details as
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.4/testing/Limited/,
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.5/testing/Limited/ and
http://dbtg.thresher.com/derby/test/10.3Branch/jvm1.6/testing/Limited/

Mike Matrigali wrote:
> 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.


-- 

With regards,



Henri van de Scheur, Database Technology Group,
Sun Microsystems, Trondheim, Norway