Quantcast

[infinispan-dev] Branching proposal

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Branching proposal

Sebastian Laskawiec
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Radim Vansa
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Sebastian Laskawiec
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 <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Radim Vansa
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?

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?

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 <[hidden email]
> <mailto:[hidden email]>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Sanne Grinovero-3
In reply to this post by Sebastian Laskawiec
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 to even
older branches
  b) you're not investigating issues on master (as investigation often
implies making code changes already)

Both of these are not very practical as I generally don't expect to
backport each and every fix, and it's going to be someone else to
recommend/approve some backports *after* the problem has been
understood in depth.
You even mention "forgetting to backport refactoring" ? Hell yes you
should never backport refactorings..

What I'm reading here is that you're all doing way too many backports.
Be more conservative about them?

In my experience with recent contributions to Infinispan - either
because the testsuite is slow, or because it takes us too long to
figure out there has been a regression, I sent a PR to master and two
maintenance branches but I had to repeat the exercise two more times
to add follow up fixes on the same subject: if I had waited on
backports it would have taken me a third of the time.

Thanks,
Sanne




On 27 March 2017 at 11:45, Sebastian Laskawiec <[hidden email]> 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.
>
> 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 <[hidden email]> 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
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Sebastian Laskawiec
In reply to this post by Radim Vansa


On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Sebastian Laskawiec
In reply to this post by Sanne Grinovero-3


On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero <[hidden email]> 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 maintenance).... just put your PR on master branch. That's all...

The proposal is all about making maintenance easier. Development stays the same.
 
Isn't it a bit naive to expect people to work on the "last maintained branch" ?

I don't think so. In that past I worked on a project with 3 maintenance branches plus a development branch. It worked. That's why I'm proposing this here.
 
Your proposal expect that each and every patch author:
  a) knows for sure it's not going to be backported further to even
older branches

As I explained this to Radim, occasional cherry-picking is totally fine. During the merge git will look at the commit, say... oh this commit is already there and move on. 
 
  b) you're not investigating issues on master (as investigation often
implies making code changes already)

Again it depends. If you do not care about maintenance branches, you can still code at master branch.

I also disagree with you here. We should always fix errors where they occur and not only in maintenance branch. If the failure is on 9.1.x branch, then the fix should go there. Not to master.
 
Both of these are not very practical as I generally don't expect to
backport each and every fix, and it's going to be someone else to
recommend/approve some backports *after* the problem has been
understood in depth.

In that kind of workflow my proposal wouldn't work well. I'm also a bit curious, how often do we need such an approval?
 
You even mention "forgetting to backport refactoring" ? Hell yes you
should never backport refactorings..

It depends. How about our checkstyle changes? After some time I guess I should have backported them to make cherry-picking easier.
 
What I'm reading here is that you're all doing way too many backports.
Be more conservative about them?

That's a very well stated question. My proposal makes the maintenance easier but developers need to be a bit more responsible (they need to know in which branch to implement a given fix and remember about doing merges). On the other hand if we prefer to encourage our users to move to more recent version quicker, than it probably doesn't make much sense.
 
In my experience with recent contributions to Infinispan - either
because the testsuite is slow, or because it takes us too long to
figure out there has been a regression, I sent a PR to master and two
maintenance branches but I had to repeat the exercise two more times
to add follow up fixes on the same subject: if I had waited on
backports it would have taken me a third of the time.

Note that my proposal partially addresses this concern. Individual PRs wouldn't need to go through CI loop but they would be merged in batches. On the other hand, even an easy merge might break the build.
 

Thanks,
Sanne




On 27 March 2017 at 11:45, Sebastian Laskawiec <[hidden email]> 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.
>
> 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 <[hidden email]> 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
>> > [hidden email]
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Dan Berindei
In reply to this post by Radim Vansa
I use something like this to check what tags contain a particular fix:

git tag --contains $(git log --grep <JIRA> -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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Radim Vansa
In reply to this post by Sebastian Laskawiec
On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote:

>
>
> On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >     > [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >     --
>     >     Radim Vansa <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>
>     >     JBoss Performance Team
>     >
>     >     _______________________________________________
>     >     infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     >
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Dan Berindei
In reply to this post by Sebastian Laskawiec
On Mon, Mar 27, 2017 at 2:51 PM, Sebastian Laskawiec
<[hidden email]> wrote:

>
>
> On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero <[hidden email]>
> 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 maintenance).... just put
> your PR on master branch. That's all...
>

The problem is that my master-only changes will also make your
maintenance changes harder to merge into master. Would you be willing
to cherry-pick others' commits into a maintenance branch just to make
your pull request apply cleanly to both branches?

> The proposal is all about making maintenance easier. Development stays the
> same.
>
>>
>> Isn't it a bit naive to expect people to work on the "last maintained
>> branch" ?
>
>
> I don't think so. In that past I worked on a project with 3 maintenance
> branches plus a development branch. It worked. That's why I'm proposing this
> here.
>
>>
>> Your proposal expect that each and every patch author:
>>   a) knows for sure it's not going to be backported further to even
>> older branches
>
>
> As I explained this to Radim, occasional cherry-picking is totally fine.
> During the merge git will look at the commit, say... oh this commit is
> already there and move on.
>

Unless the commit was already modified because of a conflict...

>>
>>   b) you're not investigating issues on master (as investigation often
>> implies making code changes already)
>
>
> Again it depends. If you do not care about maintenance branches, you can
> still code at master branch.
>
> I also disagree with you here. We should always fix errors where they occur
> and not only in maintenance branch. If the failure is on 9.1.x branch, then
> the fix should go there. Not to master.
>

I agree with Sanne. If there's already a 9.2.x branch, I really don't
want to look into all the previous releases to see if it also
reproduces there. I may not even check if it's reproducible on 9.2.x,
if I know the 10.0.x release is coming "soon".

>>
>> Both of these are not very practical as I generally don't expect to
>> backport each and every fix, and it's going to be someone else to
>> recommend/approve some backports *after* the problem has been
>> understood in depth.
>
>
> In that kind of workflow my proposal wouldn't work well. I'm also a bit
> curious, how often do we need such an approval?
>

At least in my case, I'd call it "prodding" instead of "approval", and
it happens fairly often.

>>
>> You even mention "forgetting to backport refactoring" ? Hell yes you
>> should never backport refactorings..
>
>
> It depends. How about our checkstyle changes? After some time I guess I
> should have backported them to make cherry-picking easier.
>
>>
>> What I'm reading here is that you're all doing way too many backports.
>> Be more conservative about them?
>
>
> That's a very well stated question. My proposal makes the maintenance easier
> but developers need to be a bit more responsible (they need to know in which
> branch to implement a given fix and remember about doing merges). On the
> other hand if we prefer to encourage our users to move to more recent
> version quicker, than it probably doesn't make much sense.
>

IMO we should never have more than one maintenance branch in which we
do regular backports. We may have to do the occasional backport into
older branches, but that should be the exception, not the rule.

>>
>> In my experience with recent contributions to Infinispan - either
>> because the testsuite is slow, or because it takes us too long to
>> figure out there has been a regression, I sent a PR to master and two
>> maintenance branches but I had to repeat the exercise two more times
>> to add follow up fixes on the same subject: if I had waited on
>> backports it would have taken me a third of the time.
>
>
> Note that my proposal partially addresses this concern. Individual PRs
> wouldn't need to go through CI loop but they would be merged in batches. On
> the other hand, even an easy merge might break the build.
>

-1000 to blind merges, the master build is broken enough as it is.

Cheers
Dan
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Galder Zamarreño
In reply to this post by Sebastian Laskawiec
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.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Galder Zamarreño
In reply to this post by Dan Berindei
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 <[hidden email]> wrote:
>
> I use something like this to check what tags contain a particular fix:
>
> git tag --contains $(git log --grep <JIRA> -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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

William Burns-3
In reply to this post by Galder Zamarreño


On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <[hidden email]> 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. Also, the number of backports I work on is low in general.

+1 For me the hard part is just remembering it needs to be backported. And as Sanne mentioned refactorings shouldn't really be backported and these are the types of the things that cause the most conflicts. And to be honest on some backports I might not pull every change since the real fix may have been quite small.
 

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Branching proposal

Sebastian Laskawiec
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.
  • Dan's one-liner (`git tag --contains $(git log --grep <JIRA> -1 --format="%h" master)`) very nicely replaces `git tag --contains <SHA1>` but as Galder mentioned, we should always use JIRAs. 
Thanks a lot guys for all the input!

Cheers,
Sebastian

On Tue, Mar 28, 2017 at 3:56 PM William Burns <[hidden email]> wrote:
On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <[hidden email]> 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. Also, the number of backports I work on is low in general.

+1 For me the hard part is just remembering it needs to be backported. And as Sanne mentioned refactorings shouldn't really be backported and these are the types of the things that cause the most conflicts. And to be honest on some backports I might not pull every change since the real fix may have been quite small.
 

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...