On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rva...@redhat.com> wrote:
> On 03/27/2017 12:45 PM, Sebastian Laskawiec wrote: > > From my past experience, if a commit caused a conflict when merging, > > we always asked the author to fix it and do the merge. > > I don't understand. The PR should be filed against 9.0.x, there're no > conflicts. Merging the same against master results in conflicts - where > should I resolve those? > I think we mean 9.1.x (the oldest maintenance branch). In that case you should merge 0.9.1 into 0.9.2. Than another merge 0.9.2 into master. Once the conflict occurs, a developer who does the merge should simply resolve it. > > Another q: I decide to file a PR against 9.1, because I don't think it > should be applied to 9.0. I get a review, but then someone explains that > it should get to 9.0 as well. I can't change a target branch in GitHub's > PR: should I close the PR with nice history of comments (some of them > not addressed yet) and open another PR? > You can do both (if depends on your intuition which is better). The nice thing about git merge is that it won't throw any error if a change is already present on target branch. So it is possible and legal to cherry-pick stuff as well. > > R. > > > > > After a while it became a habit that each dev who submitted a code > > that could result in conflicts, did all the merges. > > > > On Mon, Mar 27, 2017 at 12:37 PM Radim Vansa <rva...@redhat.com > > <mailto:rva...@redhat.com>> wrote: > > > > If you can't merge a commit (based on 9.0.x) to master clearly, do > you > > need to file another PR anyway? Then the lag to get some code to > > master > > increases a lot. I am not sure how useful is git tag --contains > <sha1> > > if you cannot be sure that you'll find all occurrences due to this > > kind > > of issues. > > > > R. > > > > On 03/27/2017 11:33 AM, Sebastian Laskawiec wrote: > > > Hey! > > > > > > We are about to start working on 9.1.x and 9.2.y branches so I > would > > > like to propose alternative merging strategy. > > > > > > Our current workflow looks like this: > > > > > > X - new commit > > > X` - cherry pick to maintenance branch > > > --+-------------------+-------X----- master > > > | \------X`---- 9.2.x > > > \---------------------------X``--- 9.1.x > > > > > > Each commit needs to be reviewed in master branch and backported to > > > the maintenance branches. From maintenance perspective this is a > bit > > > painful, since in above example we need to get 3 times through PR > > > queue. Also it's worth to mention that X is not X` nor X``. > > > Cherry-picking creates a copy of a commit. This makes some useful > > > tricks (like git tag --contains <sha1>) a bit harder to use. > > Finally, > > > this approach allows the codebase to diverge from maintenance > > branches > > > very fast (someone might just forget to backport some of the > > > refactoring stuff). > > > > > > The proposal: > > > > > > X, Y - new commits > > > / - merge commits > > > --+---------+------/----/--- master > > > | \----/---Y/---- 9.2.x > > > \-------------X/---------- 9.1.x > > > > > > With the proposal, a developer should always implement a given > > feature > > > in the lowest possible maintenance branch. Then we will run a set > of > > > merges from 9.1.x into 9.2.x and finally into master. The biggest > > > advantage of this approach is that given functionality > > (identified by > > > a commit) will have the same SHA1 for all branches. This will allow > > > all tools like (mentioned before) `git tag --contains <sha1>` to > > work. > > > There are also some further implications of this approach: > > > > > > * Merging commits should be performed very often (even > > automatically > > > in the night (if merged without any problems)). > > > * After releasing each maintenance release, someone will need > > to do > > > a merge with strategy `ours` (`git merge -s ours > > upstream/9.2.x`). > > > This way we will not have to solve version conflicts in poms. > > > * Since there is no nice way to rebase a merge commit, they > should > > > be pushed directly into the master branch (without review, > > without > > > CI). After the merge, HEAD will change and CI will > > > automatically pick the build. Remember, merges should be > > done very > > > often. So I assume there won't be any problems most of the > > times. > > > * Finally, with this approach the code diverges slight slower (at > > > least from my experience). Mainly because we don't need to > > > remember to cherry-pick individual commits. They are > > automatically > > > "taken" by a merge. > > > > > > From my past experience, this strategy works pretty nice and can be > > > almost fully automated. It significantly lowers the maintenance > pain > > > around cherry-picks. However there is nothing for free, and we > would > > > need to get used to pushing merged directly into master (which > > is fine > > > to me but some of you might not like it). > > > > > > Thanks, > > > Sebastian > > > > > > > > > _______________________________________________ > > > infinispan-dev mailing list > > > infinispan-dev@lists.jboss.org > > <mailto:infinispan-dev@lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > -- > > Radim Vansa <rva...@redhat.com <mailto:rva...@redhat.com>> > > JBoss Performance Team > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org <mailto: > infinispan-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
