On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote: > > > On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rva...@redhat.com > <mailto: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.
I am lost - we won't have 9.0.x as maintenance branch starting with 9.0.0.Final and 9.1.x == master moving towards 9.1.0.Final? What's 0.9.1 and 0.9.2? > > Once the conflict occurs, a developer who does the merge should simply > resolve it. You haven't explained *where*. I am a contributor, I don't "merge" stuff, I file PRs. So, I'll do a PR against [maintanance branch] with commits that can't be merged against [master] because these have conflicts. This is one PR (against [maintenance branch]). Should I issue another PR? With backports I wait until it gets into master (and usually somebody requests the backport), how do I make sure that it gets into master ASAP? > > 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> > > <mailto: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> > > <mailto: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> > <mailto: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> > <mailto: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 > <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
