AW: [VOTE] Release Apache Answer(Incubating) v1.3.1-RC2 (Round2)
+1 (binding) Chris (cdutz) [OK] Download all staged artifacts under the url specified in the release vote email. [OK] Verify the signature is correct. [OK] Check if the signature references an Apache email address. [OK] Verify the SHA512 hashes. [OK] Unzip the archive. [OK] Verify the existence of LICENSE, NOTICE, README, DISCLAIMER files in the extracted source bundle. [OK] Verify the content of LICENSE, NOTICE, README, DISCLAIMER files in the extracted source bundle. - Not WIP disclaimer, doing full checks - No files listed in NOTICE or LICENSE [OK] Run RAT externally to ensure there are no surprises. [OK] Search for SNAPSHOT references [OK] Search for Copyright references, and if they are in headers, make sure these files containing them are mentioned in the LICENSE file. [SKIPPED] Build the project according to the information in the README.md file. Didn’t build the project and didn’t inspect the binary distributions (Focused only on the source distribution, as the rest is convenience) PS: Please carry over to the incubator vote Von: Guangfu Yang Datum: Freitag, 17. Mai 2024 um 11:02 An: dev@answer.apache.org Betreff: Re: [VOTE] Release Apache Answer(Incubating) v1.3.1-RC2 (Round2) +1 approve All checklist are valid. Best regards, Kumfo - To unsubscribe, e-mail: dev-unsubscr...@answer.apache.org For additional commands, e-mail: dev-h...@answer.apache.org
AW: Quick question about the release process
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 Datum: Dienstag, 2. April 2024 um 10:26 An: dev@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 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 > Datum: Montag, 1. April 2024 um 06:07 > An: dev@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 > wrote: > > > On Mon, Apr 1, 2024 at 10:40 AM LinkinStar > 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-unsubscr...@answer.apache.org > > For additional commands, e-mail: dev-h...@answer.apache.org > > > > >
AW: Quick question about the release process
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 Datum: Montag, 1. April 2024 um 06:07 An: dev@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 wrote: > On Mon, Apr 1, 2024 at 10:40 AM LinkinStar 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-unsubscr...@answer.apache.org > For additional commands, e-mail: dev-h...@answer.apache.org > >
AW: [RESULT][VOTE] Release Apache Answer, Incubating, v1.2.0-RC1
Also do I normally wait till the project has 3 binding votes on their own before voting as a mentor. We want the project to learn to do things on their own, so I don’t want my mentor vote to get the project over the finishing line of 3 +1 votes. Chris Von: LinkinStar Datum: Freitag, 17. November 2023 um 07:45 An: dev@answer.apache.org Betreff: Re: [RESULT][VOTE] Release Apache Answer, Incubating, v1.2.0-RC1 Hi, I'm very sorry, I only noticed the number of votes and forgot to pay attention to the time. Next time I will wait for 72 hours so that more people may help us to find some issues. Best regards, LinkinStar On Fri, Nov 17, 2023 at 12:59 PM Justin Mclean wrote: > Hi, > > Waiting at least 72 hours before closing the vote is a good idea. Even if > a vote gets 3 +1 votes, someone else may find an issue that needs fixing. > > Kind Regards, > Justin > > > On 17 Nov 2023, at 1:37 pm, LinkinStar wrote: > > > > Hello everyone, > > > > The vote closes now with the following results: > > > > 3 (+1 binding) votes > > - Justin Mclean > > - Shuailing LI > > - Feng Dong > > > > > > > > I will bring the vote results to gene...@incubator.apache.org > > > > Thanks, > > LinkinStar > > > - > To unsubscribe, e-mail: dev-unsubscr...@answer.apache.org > For additional commands, e-mail: dev-h...@answer.apache.org > >
AW: About the process of releasing a binary
Well … technically we don’t „release“ binaries. Apache generally only releases sources and the binaries are considered “convenience binaries”. There is some momentum with changing this, but currently I think we’re still at the point where we don’t call them “releases”. So for your source-releases, you only need to add to the NOTICE, what’s in there … if there’s for example a maven pom.xml referencing a third party library – that’s not IN the source-release, so no need to add it. If you build maven binaries and deploy them to maven central, usually you only deploy the code of the module itself and the other stuff is pulled in via dependency. So also no need to mention it. However, if you build something like a “distribution” or you bundle other artifacts in your artifacts as some “fat-jars” then the other stuff is in there and it needs to be added to the NOTICE of the binary. I hope that explains things a bit. Chris Von: LinkinStar Datum: Freitag, 3. November 2023 um 07:46 An: dev@answer.apache.org Betreff: Re: About the process of releasing a binary Get it. Then we will collect all the dependency's licences for the binary release. Best, LinkinStar On Fri, Nov 3, 2023 at 2:20 PM Willem Jiang wrote: > Here are some instructions[1] about composing the License and Notice file. > If we provide the binary release, we must include the License file of > third-party dependencies. > > [1] https://infra.apache.org/licensing-howto.html > > > Willem Jiang > > On Thu, Nov 2, 2023 at 5:07 PM LinkinStar wrote: > > > > Hi, > > > > We are learning about the process of releasing a binary and have > > encountered a few problems. 1. If our third-party dependencies don't have > > the NOTICE, do we just need our own NOTICE when we release a binary? 2. > I'd > > like to ask if there are any Golang projects that have released binaries > in > > the past that I can learn from. > > > > Thanks. Regards > > - > To unsubscribe, e-mail: dev-unsubscr...@answer.apache.org > For additional commands, e-mail: dev-h...@answer.apache.org > >
AW: About the process of releasing a binary
Well, we don’t release the third-party dependencies, so we theoretically just use them, if the licensing is compatible. If we copy code from third-party projects, we need to keep the license headers intact and need to list which files were copied from which project and which license they were under in our NOTICE files. I hope that was correct (Wave in the direction of Justin) ;-) Chris Von: LinkinStar Datum: Donnerstag, 2. November 2023 um 10:06 An: dev@answer.apache.org Betreff: About the process of releasing a binary Hi, We are learning about the process of releasing a binary and have encountered a few problems. 1. If our third-party dependencies don't have the NOTICE, do we just need our own NOTICE when we release a binary? 2. I'd like to ask if there are any Golang projects that have released binaries in the past that I can learn from. Thanks. Regards
AW: Hello Answer Committers, can you receive this email
Hi Feng, It seems you were not subscribed, as I needed to manually moderate the message. So please subscribe ;-) Chris Von: Feng Dong Datum: Montag, 23. Oktober 2023 um 10:14 An: dev@answer.apache.org Betreff: Hello Answer Committers, can you receive this email Hello everyone, Can all Answer Committers receive emails from this mailing list by default, or do they need to subscribe manually? -- Best Regards, Feng Dong https://twitter.com/fenbox
