You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@answer.apache.org by Willem Jiang <wi...@gmail.com> on 2024/04/01 00:30:02 UTC
Quick question about the release process
Hi,
When I reviewed the release of the answer, I just found there are not
many commits on the main branch. After digging more on the commit
log, I found we just have a big PR[1] with multiple commits to merge
the release branch to the main branch within a single commit.
This approach brings some trouble for the user to look up the patches
and for the system to count the contributions of the developer. If you
take a look at the contributors graph[2] from GitHub, the recent
contribution graph cannot show all the contributions.
My question is why did we switch to the single commit release model?
[1]https://github.com/apache/incubator-answer/pull/876
[2]https://github.com/apache/incubator-answer/graphs/contributors
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
For additional commands, e-mail: dev-help@answer.apache.org
AW: Quick question about the release process
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi LinkinStar,
I’m currently digging through a huge pile of stuff, as I was on holidays for almost a week and I had done some open-source detox ;-)
Will try to squeeze it in …
Chris
Von: LinkinStar <li...@apache.org>
Datum: Dienstag, 2. April 2024 um 10:26
An: dev@answer.apache.org <de...@answer.apache.org>
Betreff: Re: Quick question about the release process
Hi Christofer Dutz,
We also find this very strange, just like what tison encountered last time.
Even more, we try to use the command line to merge and it works fine, but
GitHub's UI prompts an error. But this problem doesn't come up every time.
We can provide the PR link the next time I encounter this issue.
By the way, I have a little request for help. Could you help us by voting
for the Release Apache Answer(Incubating) v1.3.0-RC1[1]?
[1] https://lists.apache.org/thread/lh3nvmr0gr1qh869zg76q6gcjj4ll3w0
Best regards,
LinkinStar
On Tue, Apr 2, 2024 at 3:28 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> So, rebasing should never be used on any branch that has been pushed to
> the main repo.
> The only branch I regularly rebase, is my local main development branch.
>
> However, I don’t quite understand, why a “squash merge” is possible, but a
> normal merge isn’t.
> Technically they should be the same.
>
> Chris
>
>
> Von: LinkinStar <li...@apache.org>
> Datum: Montag, 1. April 2024 um 06:07
> An: dev@answer.apache.org <de...@answer.apache.org>
> Betreff: Re: Quick question about the release process
> Hi Willem Jiang,
>
> You are absolutely correct in what you said. Just as you said, we also do
> not want to use commands like "git push --force" as they can cause many
> issues.
>
> The solution, as you mentioned, is to use the svn-like-model to replace the
> current git-flow-model, which would help avoid this problem. Our team will
> discuss this matter and consider whether we can adopt such a development
> collaboration model in the future.
>
> Thanks again for your suggestions.
>
> Best regards,
> LinkinStar
>
> On Mon, Apr 1, 2024 at 11:37 AM Willem Jiang <wi...@gmail.com>
> wrote:
>
> > On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <li...@apache.org>
> wrote:
> > >
> > > Hi Willem Jiang,
> > >
> > > First of all, thank you for your question.
> > >
> > > Firstly, regarding the merging of PRs, we encountered the same issue as
> > > tisonkun before[1]. During the merge process, we are unable to select
> the
> > > "Rebase and merge" option and are forced to choose "Squash and merge."
> > This
> > > results in the effect of merging commits that you mentioned.
> > > We can confirm that we cannot select the "Create a merge commit" and
> > > "Rebase and merge" options. Furthermore, there are *no conflicts*
> between
> > > our branch and the main branch during the merge, *as we also attempted
> a
> > > manual merge without conflicts*. Additionally, we cannot resolve this
> > issue
> > > through manual merging because we cannot push directly to the main
> branch
> > > using git commands; we can only merge the PR using the GitHub web UI.
> In
> > > conclusion, we have no other choice but to select the "Squash and
> merge"
> > > option.
> > >
> >
> > As the rebase merge approach could change the commit logs of the
> > branch which were already published.
> > Normally we can use force push to republish the branch, but it could
> > cause some trouble for the client to consume the repo.
> >
> >
> > > Secondly, regarding the issue you mentioned about contributors not
> being
> > > displayed in the contributors graph, we have just verified it. *All
> > > contributors from the latest version are shown in the contributors
> > graph.*
> > > If you did not see them, we believe this issue might be due to GitHub's
> > > caching, as the contributors graph is not real-time maybe. Below is the
> > > list of contributors, excluding members from our internal team.
> > >
> > > [x] hgaol
> > > [x] xpume
> > > [x] zahash
> > > [x] hbsciw
> > > [x] sy-records
> > > [x] foxzero-007
> > > [x] surapuramakhil
> > > [x] Octobug
> > >
> >
> > As the PR merged, all the commits were squashed, their contribution
> > only shown in one merged commit.
> >
> >
> > > Lastly, thank you again for your question. If you have any other
> > > suggestions, please feel free to continue sharing and discussing.
> > >
> >
> > To keep the commit log with squash and merge approach, we may consider
> > switching the developer process to (svn-like-model) commit all the
> > changes to the main branch first and create the maintenance branch
> > after the release from main if needed. In this way all the commits
> > were added to the main branch as smaller pieces, we just cherry-picked
> > patches to fork the branch to fix the bugs.
> >
> >
> > > [1] https://github.com/apache/incubator-answer/pull/633
> > >
> > > Best regards,
> > > LinkinStar
> > >
> >
> >
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
> > For additional commands, e-mail: dev-help@answer.apache.org
> >
> >
>
Re: Quick question about the release process
Posted by LinkinStar <li...@apache.org>.
Hi Christofer Dutz,
We also find this very strange, just like what tison encountered last time.
Even more, we try to use the command line to merge and it works fine, but
GitHub's UI prompts an error. But this problem doesn't come up every time.
We can provide the PR link the next time I encounter this issue.
By the way, I have a little request for help. Could you help us by voting
for the Release Apache Answer(Incubating) v1.3.0-RC1[1]?
[1] https://lists.apache.org/thread/lh3nvmr0gr1qh869zg76q6gcjj4ll3w0
Best regards,
LinkinStar
On Tue, Apr 2, 2024 at 3:28 PM Christofer Dutz <ch...@c-ware.de>
wrote:
> So, rebasing should never be used on any branch that has been pushed to
> the main repo.
> The only branch I regularly rebase, is my local main development branch.
>
> However, I don’t quite understand, why a “squash merge” is possible, but a
> normal merge isn’t.
> Technically they should be the same.
>
> Chris
>
>
> Von: LinkinStar <li...@apache.org>
> Datum: Montag, 1. April 2024 um 06:07
> An: dev@answer.apache.org <de...@answer.apache.org>
> Betreff: Re: Quick question about the release process
> Hi Willem Jiang,
>
> You are absolutely correct in what you said. Just as you said, we also do
> not want to use commands like "git push --force" as they can cause many
> issues.
>
> The solution, as you mentioned, is to use the svn-like-model to replace the
> current git-flow-model, which would help avoid this problem. Our team will
> discuss this matter and consider whether we can adopt such a development
> collaboration model in the future.
>
> Thanks again for your suggestions.
>
> Best regards,
> LinkinStar
>
> On Mon, Apr 1, 2024 at 11:37 AM Willem Jiang <wi...@gmail.com>
> wrote:
>
> > On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <li...@apache.org>
> wrote:
> > >
> > > Hi Willem Jiang,
> > >
> > > First of all, thank you for your question.
> > >
> > > Firstly, regarding the merging of PRs, we encountered the same issue as
> > > tisonkun before[1]. During the merge process, we are unable to select
> the
> > > "Rebase and merge" option and are forced to choose "Squash and merge."
> > This
> > > results in the effect of merging commits that you mentioned.
> > > We can confirm that we cannot select the "Create a merge commit" and
> > > "Rebase and merge" options. Furthermore, there are *no conflicts*
> between
> > > our branch and the main branch during the merge, *as we also attempted
> a
> > > manual merge without conflicts*. Additionally, we cannot resolve this
> > issue
> > > through manual merging because we cannot push directly to the main
> branch
> > > using git commands; we can only merge the PR using the GitHub web UI.
> In
> > > conclusion, we have no other choice but to select the "Squash and
> merge"
> > > option.
> > >
> >
> > As the rebase merge approach could change the commit logs of the
> > branch which were already published.
> > Normally we can use force push to republish the branch, but it could
> > cause some trouble for the client to consume the repo.
> >
> >
> > > Secondly, regarding the issue you mentioned about contributors not
> being
> > > displayed in the contributors graph, we have just verified it. *All
> > > contributors from the latest version are shown in the contributors
> > graph.*
> > > If you did not see them, we believe this issue might be due to GitHub's
> > > caching, as the contributors graph is not real-time maybe. Below is the
> > > list of contributors, excluding members from our internal team.
> > >
> > > [x] hgaol
> > > [x] xpume
> > > [x] zahash
> > > [x] hbsciw
> > > [x] sy-records
> > > [x] foxzero-007
> > > [x] surapuramakhil
> > > [x] Octobug
> > >
> >
> > As the PR merged, all the commits were squashed, their contribution
> > only shown in one merged commit.
> >
> >
> > > Lastly, thank you again for your question. If you have any other
> > > suggestions, please feel free to continue sharing and discussing.
> > >
> >
> > To keep the commit log with squash and merge approach, we may consider
> > switching the developer process to (svn-like-model) commit all the
> > changes to the main branch first and create the maintenance branch
> > after the release from main if needed. In this way all the commits
> > were added to the main branch as smaller pieces, we just cherry-picked
> > patches to fork the branch to fix the bugs.
> >
> >
> > > [1] https://github.com/apache/incubator-answer/pull/633
> > >
> > > Best regards,
> > > LinkinStar
> > >
> >
> >
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
> > For additional commands, e-mail: dev-help@answer.apache.org
> >
> >
>
AW: Quick question about the release process
Posted by Christofer Dutz <ch...@c-ware.de>.
So, rebasing should never be used on any branch that has been pushed to the main repo.
The only branch I regularly rebase, is my local main development branch.
However, I don’t quite understand, why a “squash merge” is possible, but a normal merge isn’t.
Technically they should be the same.
Chris
Von: LinkinStar <li...@apache.org>
Datum: Montag, 1. April 2024 um 06:07
An: dev@answer.apache.org <de...@answer.apache.org>
Betreff: Re: Quick question about the release process
Hi Willem Jiang,
You are absolutely correct in what you said. Just as you said, we also do
not want to use commands like "git push --force" as they can cause many
issues.
The solution, as you mentioned, is to use the svn-like-model to replace the
current git-flow-model, which would help avoid this problem. Our team will
discuss this matter and consider whether we can adopt such a development
collaboration model in the future.
Thanks again for your suggestions.
Best regards,
LinkinStar
On Mon, Apr 1, 2024 at 11:37 AM Willem Jiang <wi...@gmail.com> wrote:
> On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <li...@apache.org> wrote:
> >
> > Hi Willem Jiang,
> >
> > First of all, thank you for your question.
> >
> > Firstly, regarding the merging of PRs, we encountered the same issue as
> > tisonkun before[1]. During the merge process, we are unable to select the
> > "Rebase and merge" option and are forced to choose "Squash and merge."
> This
> > results in the effect of merging commits that you mentioned.
> > We can confirm that we cannot select the "Create a merge commit" and
> > "Rebase and merge" options. Furthermore, there are *no conflicts* between
> > our branch and the main branch during the merge, *as we also attempted a
> > manual merge without conflicts*. Additionally, we cannot resolve this
> issue
> > through manual merging because we cannot push directly to the main branch
> > using git commands; we can only merge the PR using the GitHub web UI. In
> > conclusion, we have no other choice but to select the "Squash and merge"
> > option.
> >
>
> As the rebase merge approach could change the commit logs of the
> branch which were already published.
> Normally we can use force push to republish the branch, but it could
> cause some trouble for the client to consume the repo.
>
>
> > Secondly, regarding the issue you mentioned about contributors not being
> > displayed in the contributors graph, we have just verified it. *All
> > contributors from the latest version are shown in the contributors
> graph.*
> > If you did not see them, we believe this issue might be due to GitHub's
> > caching, as the contributors graph is not real-time maybe. Below is the
> > list of contributors, excluding members from our internal team.
> >
> > [x] hgaol
> > [x] xpume
> > [x] zahash
> > [x] hbsciw
> > [x] sy-records
> > [x] foxzero-007
> > [x] surapuramakhil
> > [x] Octobug
> >
>
> As the PR merged, all the commits were squashed, their contribution
> only shown in one merged commit.
>
>
> > Lastly, thank you again for your question. If you have any other
> > suggestions, please feel free to continue sharing and discussing.
> >
>
> To keep the commit log with squash and merge approach, we may consider
> switching the developer process to (svn-like-model) commit all the
> changes to the main branch first and create the maintenance branch
> after the release from main if needed. In this way all the commits
> were added to the main branch as smaller pieces, we just cherry-picked
> patches to fork the branch to fix the bugs.
>
>
> > [1] https://github.com/apache/incubator-answer/pull/633
> >
> > Best regards,
> > LinkinStar
> >
>
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
> For additional commands, e-mail: dev-help@answer.apache.org
>
>
Re: Quick question about the release process
Posted by LinkinStar <li...@apache.org>.
Hi Willem Jiang,
You are absolutely correct in what you said. Just as you said, we also do
not want to use commands like "git push --force" as they can cause many
issues.
The solution, as you mentioned, is to use the svn-like-model to replace the
current git-flow-model, which would help avoid this problem. Our team will
discuss this matter and consider whether we can adopt such a development
collaboration model in the future.
Thanks again for your suggestions.
Best regards,
LinkinStar
On Mon, Apr 1, 2024 at 11:37 AM Willem Jiang <wi...@gmail.com> wrote:
> On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <li...@apache.org> wrote:
> >
> > Hi Willem Jiang,
> >
> > First of all, thank you for your question.
> >
> > Firstly, regarding the merging of PRs, we encountered the same issue as
> > tisonkun before[1]. During the merge process, we are unable to select the
> > "Rebase and merge" option and are forced to choose "Squash and merge."
> This
> > results in the effect of merging commits that you mentioned.
> > We can confirm that we cannot select the "Create a merge commit" and
> > "Rebase and merge" options. Furthermore, there are *no conflicts* between
> > our branch and the main branch during the merge, *as we also attempted a
> > manual merge without conflicts*. Additionally, we cannot resolve this
> issue
> > through manual merging because we cannot push directly to the main branch
> > using git commands; we can only merge the PR using the GitHub web UI. In
> > conclusion, we have no other choice but to select the "Squash and merge"
> > option.
> >
>
> As the rebase merge approach could change the commit logs of the
> branch which were already published.
> Normally we can use force push to republish the branch, but it could
> cause some trouble for the client to consume the repo.
>
>
> > Secondly, regarding the issue you mentioned about contributors not being
> > displayed in the contributors graph, we have just verified it. *All
> > contributors from the latest version are shown in the contributors
> graph.*
> > If you did not see them, we believe this issue might be due to GitHub's
> > caching, as the contributors graph is not real-time maybe. Below is the
> > list of contributors, excluding members from our internal team.
> >
> > [x] hgaol
> > [x] xpume
> > [x] zahash
> > [x] hbsciw
> > [x] sy-records
> > [x] foxzero-007
> > [x] surapuramakhil
> > [x] Octobug
> >
>
> As the PR merged, all the commits were squashed, their contribution
> only shown in one merged commit.
>
>
> > Lastly, thank you again for your question. If you have any other
> > suggestions, please feel free to continue sharing and discussing.
> >
>
> To keep the commit log with squash and merge approach, we may consider
> switching the developer process to (svn-like-model) commit all the
> changes to the main branch first and create the maintenance branch
> after the release from main if needed. In this way all the commits
> were added to the main branch as smaller pieces, we just cherry-picked
> patches to fork the branch to fix the bugs.
>
>
> > [1] https://github.com/apache/incubator-answer/pull/633
> >
> > Best regards,
> > LinkinStar
> >
>
>
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
> For additional commands, e-mail: dev-help@answer.apache.org
>
>
Re: Quick question about the release process
Posted by Willem Jiang <wi...@gmail.com>.
On Mon, Apr 1, 2024 at 10:40 AM LinkinStar <li...@apache.org> wrote:
>
> Hi Willem Jiang,
>
> First of all, thank you for your question.
>
> Firstly, regarding the merging of PRs, we encountered the same issue as
> tisonkun before[1]. During the merge process, we are unable to select the
> "Rebase and merge" option and are forced to choose "Squash and merge." This
> results in the effect of merging commits that you mentioned.
> We can confirm that we cannot select the "Create a merge commit" and
> "Rebase and merge" options. Furthermore, there are *no conflicts* between
> our branch and the main branch during the merge, *as we also attempted a
> manual merge without conflicts*. Additionally, we cannot resolve this issue
> through manual merging because we cannot push directly to the main branch
> using git commands; we can only merge the PR using the GitHub web UI. In
> conclusion, we have no other choice but to select the "Squash and merge"
> option.
>
As the rebase merge approach could change the commit logs of the
branch which were already published.
Normally we can use force push to republish the branch, but it could
cause some trouble for the client to consume the repo.
> Secondly, regarding the issue you mentioned about contributors not being
> displayed in the contributors graph, we have just verified it. *All
> contributors from the latest version are shown in the contributors graph.*
> If you did not see them, we believe this issue might be due to GitHub's
> caching, as the contributors graph is not real-time maybe. Below is the
> list of contributors, excluding members from our internal team.
>
> [x] hgaol
> [x] xpume
> [x] zahash
> [x] hbsciw
> [x] sy-records
> [x] foxzero-007
> [x] surapuramakhil
> [x] Octobug
>
As the PR merged, all the commits were squashed, their contribution
only shown in one merged commit.
> Lastly, thank you again for your question. If you have any other
> suggestions, please feel free to continue sharing and discussing.
>
To keep the commit log with squash and merge approach, we may consider
switching the developer process to (svn-like-model) commit all the
changes to the main branch first and create the maintenance branch
after the release from main if needed. In this way all the commits
were added to the main branch as smaller pieces, we just cherry-picked
patches to fork the branch to fix the bugs.
> [1] https://github.com/apache/incubator-answer/pull/633
>
> Best regards,
> LinkinStar
>
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
For additional commands, e-mail: dev-help@answer.apache.org
Re: Quick question about the release process
Posted by LinkinStar <li...@apache.org>.
Hi Willem Jiang,
First of all, thank you for your question.
Firstly, regarding the merging of PRs, we encountered the same issue as
tisonkun before[1]. During the merge process, we are unable to select the
"Rebase and merge" option and are forced to choose "Squash and merge." This
results in the effect of merging commits that you mentioned.
We can confirm that we cannot select the "Create a merge commit" and
"Rebase and merge" options. Furthermore, there are *no conflicts* between
our branch and the main branch during the merge, *as we also attempted a
manual merge without conflicts*. Additionally, we cannot resolve this issue
through manual merging because we cannot push directly to the main branch
using git commands; we can only merge the PR using the GitHub web UI. In
conclusion, we have no other choice but to select the "Squash and merge"
option.
Secondly, regarding the issue you mentioned about contributors not being
displayed in the contributors graph, we have just verified it. *All
contributors from the latest version are shown in the contributors graph.*
If you did not see them, we believe this issue might be due to GitHub's
caching, as the contributors graph is not real-time maybe. Below is the
list of contributors, excluding members from our internal team.
[x] hgaol
[x] xpume
[x] zahash
[x] hbsciw
[x] sy-records
[x] foxzero-007
[x] surapuramakhil
[x] Octobug
Lastly, thank you again for your question. If you have any other
suggestions, please feel free to continue sharing and discussing.
[1] https://github.com/apache/incubator-answer/pull/633
Best regards,
LinkinStar
On Mon, Apr 1, 2024 at 8:30 AM Willem Jiang <wi...@gmail.com> wrote:
> Hi,
>
> When I reviewed the release of the answer, I just found there are not
> many commits on the main branch. After digging more on the commit
> log, I found we just have a big PR[1] with multiple commits to merge
> the release branch to the main branch within a single commit.
>
> This approach brings some trouble for the user to look up the patches
> and for the system to count the contributions of the developer. If you
> take a look at the contributors graph[2] from GitHub, the recent
> contribution graph cannot show all the contributions.
>
> My question is why did we switch to the single commit release model?
>
> [1]https://github.com/apache/incubator-answer/pull/876
> [2]https://github.com/apache/incubator-answer/graphs/contributors
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@answer.apache.org
> For additional commands, e-mail: dev-help@answer.apache.org
>
>