Re: [infinispan-dev] Branching proposal

Ok, I think I can try to sum this proposal and discussion up: - The proposal doesn't fit well into our workflow. - We are more focused on developing in master branch and do occasional (and sometimes partial) backports. - We use at most one maintenance branch, so there's no big deal.

Re: [infinispan-dev] Branching proposal

On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño wrote: > Why are we working in 9.1.x, 9.2.x and master in paralell? We normally > work on master and maybe one more maintenance branch. > > Except for occasional tricky backports (e.g. Radim's work) the rest has > been pretty straightforward for me

Re: [infinispan-dev] Branching proposal

Nice one-liner. The fact that we always put the JIRA id helps. Cheers, -- Galder Zamarreño Infinispan, Red Hat > On 27 Mar 2017, at 14:36, Dan Berindei wrote: > > I use something like this to check what tags contain a particular fix: > > git tag --contains $(git log --grep -1 --format="%h" ma

Re: [infinispan-dev] Branching proposal

Why are we working in 9.1.x, 9.2.x and master in paralell? We normally work on master and maybe one more maintenance branch. Except for occasional tricky backports (e.g. Radim's work) the rest has been pretty straightforward for me. Also, the number of backports I work on is low in general. Ch

Re: [infinispan-dev] Branching proposal

On Mon, Mar 27, 2017 at 2:51 PM, Sebastian Laskawiec wrote: > > > On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero > wrote: >> >> You need to make sure you optimise for engineers coding stuff which >> works on master, not maintenance. > > > Well it depends on your strategy. Note that with my propo

Re: [infinispan-dev] Branching proposal

On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote: > > > On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa > 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 t

Re: [infinispan-dev] Branching proposal

I use something like this to check what tags contain a particular fix: git tag --contains $(git log --grep -1 --format="%h" master) True, it's a bit longer, but it stays in the bash/zsh history :) Cheers Dan On Mon, Mar 27, 2017 at 1:33 PM, Radim Vansa wrote: > If you can't merge a commit (b

Re: [infinispan-dev] Branching proposal

On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero wrote: > You need to make sure you optimise for engineers coding stuff which > works on master, not maintenance. > Well it depends on your strategy. Note that with my proposal you can always do that (optimize features for development not for mainte

Re: [infinispan-dev] Branching proposal

On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa 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

Re: [infinispan-dev] Branching proposal

You need to make sure you optimise for engineers coding stuff which works on master, not maintenance. Isn't it a bit naive to expect people to work on the "last maintained branch" ? Your proposal expect that each and every patch author: a) knows for sure it's not going to be backported further

Re: [infinispan-dev] Branching proposal

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 resu

Re: [infinispan-dev] Branching proposal

>From my past experience, if a commit caused a conflict when merging, we always asked the author to fix it and do the merge. 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 wrote:

Re: [infinispan-dev] Branching proposal

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 if you cannot be sure that you'll find all occurrences due to this kind of issues. R.

[infinispan-dev] Branching proposal

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