The usual way we do this in other projects is the 1st option. We can create a new JIRA for the merge, then submit the patch with the conflicts resolved, wait for tests, then commit it.
Although the 2nd option looks easier if we only missing one commit, but I think we should avoid it just in case we missed to port some commits from master to the branch. If you don't want to include SENTRY-1205, then just revert it from master, and then do the merge from sentry-ha-design to master. That would work. On Wed, Mar 22, 2017 at 3:43 PM, Alexander Kolbasov <ak...@cloudera.com> wrote: > Hello, > > I would like to start the discussion on merging sentry-ha-redesign branch > with master. > > As of now most of the changes from master are merged into > sentry-ha-redesign. The major missing part is SENTRY-1205 (Refactor the > code for sentry-provider-db and create sentry-service module) and > associated issues. This refactoring is very hard to port, especially since > there is very little information in the JIRA on why it was done and how it > was done - was it merely moving files around or more then that. I would > seriously consider not including this change in 1.8. > > So in regards to the merge we have several options: > > > - Attempt to merge master into sentry-ha-redesign, resolve any conflicts > and later commit the merge to master. This will cause merge commit on > master > - Finish work on sentry-ha-redesign, make sure that relevant commits are > ported from master, and then making this a master branch and making > current > master a special branch left for reference purposes. This will likely > leave > SENTRY-1205 and related issues out. > > What does community think about this? > > - Alex >
