-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 14 May 2009 13:11:19 +0200 Jan Pazdziora <jpazdzi...@redhat.com> wrote:
> On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote: > > All, > > > > I'd like to start getting some eyes on the pgsql branch in > > preparation of a merge to master. So far, the changes on this > > branch have been focused on porting the schema and updating the > > application infrastructure to work with both oracle and postgres > > databases. > > This might be a technicality but: do we want to merge or cherry pick? > If we want to start with infrastructure work, I assume we will want to > bring in the changes to master in small steps, addressing one issue at > a time (SQL standard compliance, table / trigger DDL split, etc.). > That way, the changes will have a chance to get verified and tested > in Oracle environment while the diff against the pgsql branch will > get smaller. > > I would not want to see huge merge commit landing in master. > > (I will probably send more responses to your post, commenting on > one issue at a time.) > I do not think this is a good course of action for a number of reasons. Firstly the end state of the branch is the only thing we really know to be working, everything in between could have bugs that we later discovered and fixed but there's no sane way to know what commit goes with what, and changes can depend on other changes in very different locations in the code base. Re-doing the changes with individual cherry-picks will amount to a tremendous amount of overhead as we verify and re-verify everything. Secondly all the work we did to merge in master periodically and resolve the conflicts would be thrown out, we'd get to do it all over again, only now for every patch we cherry-pick that conflicts as opposed to once and only once per merge. There will be a big merge commit (though it is not a huge diff) as the two trees rejoin, but they've been merged together periodically anyhow. This is how long spanning feature work is meant to be done with git. I don't think cherry-picking every individual commit would even really buy us anything. Sure the diff starts shrinking but for the above reasons this probably doesn't mean anything except that we likely have bugs with what we've taken so far and need to go digging to find the commits that they depend on, or to determine if it's a newly discovered issue. IMO we committed to this strategy some time ago, and merge back is our best option by far. Cheers, Devan - -- Devan Goodwin <dgood...@redhat.com> Software Engineer Spacewalk / RHN Satellite Halifax, Canada 650.567.9039x79267 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkoUA+wACgkQAyHWaPV9my7BaQCeLb/mm14U4PTMw1bwJAWznhxK 6AEAoMfpu6JritobZ3hkgm38WJCX7hRo =q/ML -----END PGP SIGNATURE----- _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
