On Fri, Jun 6, 2014 at 4:44 PM, Andrew Purtell <apurt...@apache.org> wrote:
> On Fri, Jun 6, 2014 at 4:36 PM, Jonathan Hsieh <j...@cloudera.com> wrote: > > > Personally I prefer the merge for these large feature branches -- it > > guarantees that each commit is compilable, and reflects what you guys > have > > been testing for a while. If you go with the last approach you might > have > > stuff broken, and in the mainline commit path. > > > > This is why I asked for the final patches to be broken out with git > format-patch and attached to the JIRA, so we know what was finally > committed. > Fair enough. I thought that the canonical version of the patch is always in repo anyway, but I'll upload the patches. > > To allay these concerns it would be great, if rebasing the 10070 patches > consecutively on top of trunk, to check that the result passes the typical > release candidate checks and only push after it checks out. > Agreed. I'll be running the UT + some tests before the push. > > My opinion is this need not be a requirement, even with a history > preserving merge into trunk we can end up in a broken state if fixups are > committed in the merge commit. We would have the additional complication of > a delta committed in the merge commit not directly associated with a JIRA. > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White) >
