11:33 a.m.
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
12:33 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
12:45 p.m.
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 <rvansa(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
12:59 p.m.
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 <rvansa(a)redhat.com
<mailto:rvansa@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(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
1:16 p.m.
On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rvansa(a)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 <rvansa(a)redhat.com
> <mailto:rvansa@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(a)lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2:41 p.m.
On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote:
On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rvansa(a)redhat.com
<mailto:rvansa@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 <rvansa(a)redhat.com
<mailto:rvansa@redhat.com>
> <mailto:rvansa@redhat.com <mailto:rvansa@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(a)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 <rvansa(a)redhat.com <mailto:rvansa@redhat.com>
<mailto:rvansa@redhat.com <mailto:rvansa@redhat.com>>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)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(a)lists.jboss.org
<mailto:infinispan-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
1:04 p.m.
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 <slaskawi(a)redhat.com> 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 <rvansa(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:51 p.m.
On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero <sanne(a)infinispan.org>
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 <slaskawi(a)redhat.com>
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 <rvansa(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <rvansa(a)redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:26 p.m.
On Mon, Mar 27, 2017 at 2:51 PM, Sebastian Laskawiec
<slaskawi(a)redhat.com> wrote:
On Mon, Mar 27, 2017 at 1:05 PM Sanne Grinovero <sanne(a)infinispan.org>
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
2:36 p.m.
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 <rvansa(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:16 a.m.
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 <dan.berindei(a)gmail.com>
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 <rvansa(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:15 a.m.
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
<slaskawi(a)redhat.com> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
3:36 p.m.
On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <galder(a)redhat.com> 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 <slaskawi(a)redhat.com>
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
11:45 a.m.
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 <mudokonman(a)gmail.com> wrote:
On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño
<galder(a)redhat.com>
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 <slaskawi(a)redhat.com>
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
2606
days inactive
2609
days old
infinispan-dev@lists.jboss.org
13 comments
6 participants
participants (6)
-
Dan Berindei -
Galder Zamarreño -
Radim Vansa -
Sanne Grinovero -
Sebastian Laskawiec -
William Burns