I tried the mega merge approach this time and ended up with a conflict
on one of the patches which had been ported previously. I don't know if
there was something special about the patch or if that's just to be
expected. So I broke the merge up into mini-merges whose endpoints were
the patches which had been ported already. That resulted in no
conflicts. Any regular policy would simplify the job of the release
manager. Unfortunately, regardless of the policy, people will make
mistakes and create outlying cases. It's those outliers which complicate
the process. All in all, I prefer the following policy--but I'm still
going to have to sanity check the submission comments on every patch:
1) Don't bother merging from the trunk to the branch. I'll sweep up
these changes in a mega-merge.
2) However, if you think a patch should not be ported to 10.2, then
please note that in the table at the end of this 10.2 wiki page:
http://wiki.apache.org/db-derby/TenTwoRelease.
This time around, the following patches were not merged. All of the
others were merged either by me or by the original committers:
r437215 | bpendleton | 2006-08-26 12:42:02 -0700 (Sat, 26 Aug 2006) | 18
lines
DERBY-119: Add ALTER TABLE option to change column from NULL to NOT NULL
r438942 | mikem | 2006-08-31 07:39:55 -0700 (Thu, 31 Aug 2006) | 11 lines
DERBY-1583 contributed by Bryan Pendleton
Thanks,
-Rick
Mike Matrigali wrote:
Rick Hillegas wrote:
Thanks for the warning, Mike. I'm cautiously hopeful that this won't
be a problem. I'll find out!
Regards,
-Rick
Definitely let us know which makes the work easier. For most changes I
would be happy to commit to trunk and wait for the mega merge to move
them to the branch.
