[DISCUSS] Weekly build and prepare for releasing 1.0
Hi All, At present, the main features of version 1.0 are in the final stage of development. Stability and bug fixing work will be carried out later. We are currently encountering some problems: 1. some features that have not been fully validated have been merged in, affecting the testing of existing features, resulting in problems that have not been converged. 2. have been unable to maintain a stable baseline version, resulting in uncontrollable release cycle. In response, I will take the following steps to ensure that the problem is converged and manageable. 1. PR tagging All PRs must be labeled with the following tags. For example, dev-1.0.0 for the first week and dev-1.0.1 for the second week. After the branch is created, the branch will only selectively merge in PRs tagged with "dev/1.0.0". All subsequent PRs must be labeled as follows. - dev/1.0.0: Indicates that this PR needs to be merged into the dev-1.0.0 branch. - dev/backlog: Indicates that the PR is not to be merged into any dev branch at this time. When a PR labeled with "dev/backlog" is explicitly to be merged into a dev branch, remove the "dev/backlog" label and add the dev label of the corresponding branch. 2. PR merge principle After a PR Approve, it should, in principle, stay at least one day before it is merged in, so that other reviewers can make possible confirmation. If you need to merge quickly, please comment in the PR to explain the reason. All PRs must have a clear dev label before merging in. The final Release version will be generated from the dev branch. I will follow up and push for this to happen, if others would like to participate in this effort, or have suggestions or comments, please feel free to discuss. -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org
Re:[DISCUSS] Weekly build and prepare for releasing 1.0
And I have created the first branch dev-1.0.0[1], which is up to the commit #0726a43 and create 2 new labels: dev/1.0.0 and dev/1.0.1 [1] https://github.com/apache/incubator-doris/tree/dev-1.0.0 -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org At 2022-02-23 23:44:18, "陈明雨" wrote: >Hi All, >At present, the main features of version 1.0 are in the final stage of >development. Stability and bug fixing work will be carried out later. >We are currently encountering some problems: >1. some features that have not been fully validated have been merged in, >affecting the testing of existing features, resulting in problems that have >not been converged. >2. have been unable to maintain a stable baseline version, resulting in >uncontrollable release cycle. > > >In response, I will take the following steps to ensure that the problem is >converged and manageable. > > >1. PR tagging >All PRs must be labeled with the following tags. >For example, dev-1.0.0 for the first week and dev-1.0.1 for the second > week. >After the branch is created, the branch will only selectively merge in PRs > tagged with "dev/1.0.0". >All subsequent PRs must be labeled as follows. >- dev/1.0.0: Indicates that this PR needs to be merged into the > dev-1.0.0 branch. >- dev/backlog: Indicates that the PR is not to be merged into any dev > branch at this time. >When a PR labeled with "dev/backlog" is explicitly to be merged into a dev > branch, remove the "dev/backlog" label and add the dev label of the > corresponding branch. > > >2. PR merge principle >After a PR Approve, it should, in principle, stay at least one day before > it is merged in, so that other reviewers can make possible confirmation. >If you need to merge quickly, please comment in the PR to explain the > reason. >All PRs must have a clear dev label before merging in. > > >The final Release version will be generated from the dev branch. >I will follow up and push for this to happen, if others would like to >participate in this effort, or have suggestions or comments, please feel free >to discuss. > > > >-- > >此致！Best Regards >陈明雨 Mingyu Chen > >Email: >chenmin...@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
+1 -- Original -- From: 陈明雨
Re: [VOTE] Release Flink Connectors v1.0.2 for Apache Doris(Incubating)
+1. I checked the License and Notice file There is no binary in the source release kit. We have the incubating disclarm in the source file. I finally built the binary from the source kit in my macbook pro. There are some things we can do before the next release. 1. We need to add how to build in the README 2. Need to mention installation of thrift first 3. We don't need to sign the kit when using mvn clean install by default, we can add a release profile for signing the kit. Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Feb 22, 2022 at 11:43 AM 陈明雨 wrote: > > Hi All, > > > > > This is a call for vote to release Flink Connectors v1.0.2 for Apache > Doris(Incubating). > > There are 4 outputs for different Flink versions: > > > > > - apache-doris-flink-connector-1.11.6-2.12-1.0.2-incubating > > - apache-doris-flink-connector-1.12.7-2.12-1.0.2-incubating > > - apache-doris-flink-connector-1.13.5-2.12-1.0.2-incubating > - apache-doris-flink-connector-1.14.3-2.12-1.0.2-incubating > > > > > This is the first version of flink connector, and 1.0.2 is used because we > have used versions 1.0.0 and 1.0.1 for pre-release before, and these 2 > versions are deprecated. > We have just moved the code from[1] to [2]. > > > > > The release candidates: > > https://dist.apache.org/repos/dist/dev/incubator/doris/flink-connector/1.0.2/ > > > > > Maven 2 staging repository: > > https://repository.apache.org/content/repositories/orgapachedoris-1004/org/apache/doris/doris-flink-connector/ > > > > Git tag for the release: > > https://github.com/apache/incubator-doris-flink-connector/tree/1.11.6-2.12-1.0.2 > > https://github.com/apache/incubator-doris-flink-connector/tree/1.12.7-2.12-1.0.2 > > https://github.com/apache/incubator-doris-flink-connector/tree/1.13.5-2.12-1.0.2 > https://github.com/apache/incubator-doris-flink-connector/tree/1.14.3-2.12-1.0.2 > > > > > Keys to verify the Release Candidate: > > https://downloads.apache.org/incubator/doris/KEYS > > > > > Look at here for how to verify this release candidate: > > http://doris.incubator.apache.org/community/release-and-verify/release-verify.html > > > > > The vote will be open for at least 72 hours or until necessary number of > votes are reached. > > > > > Please vote accordingly: > > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > > [1] https://github.com/apache/incubator-doris > > [2] https://github.com/apache/incubator-doris-flink-connector > > > > > -- > > 此致！Best Regards > 陈明雨 Mingyu Chen > > Email: > chenmin...@apache.org - To unsubscribe, e-mail: dev-unsubscr...@doris.apache.org For additional commands, e-mail: dev-h...@doris.apache.org
Re: [VOTE] Release Flink Connectors v1.0.2 for Apache Doris(Incubating)
+1 I have verified the checkability below： [x] Is the download link legal? [x] Check whether the value and PGP signature are legal. [x] Whether to include a DISCLAIMER or DISCLAIMER-WIP file. [x] Whether the code matches the current release version. [x] LICENSE and NOTICE files are correct. [x] All documents carry the necessary protocol descriptions. [x] The compiled content is not included in the source package. Ling Miao Willem Jiang 于2022年2月24日周四 11:03写道： > +1. > I checked the License and Notice file > There is no binary in the source release kit. > We have the incubating disclarm in the source file. > I finally built the binary from the source kit in my macbook pro. > > There are some things we can do before the next release. > 1. We need to add how to build in the README > 2. Need to mention installation of thrift first > 3. We don't need to sign the kit when using mvn clean install by > default, we can add a release profile for signing the kit. > > Willem Jiang > > Twitter: willemjiang > Weibo: 姜宁willem > > On Tue, Feb 22, 2022 at 11:43 AM 陈明雨 wrote: > > > > Hi All, > > > > > > > > > > This is a call for vote to release Flink Connectors v1.0.2 for Apache > Doris(Incubating). > > > > There are 4 outputs for different Flink versions: > > > > > > > > > > - apache-doris-flink-connector-1.11.6-2.12-1.0.2-incubating > > > > - apache-doris-flink-connector-1.12.7-2.12-1.0.2-incubating > > > > - apache-doris-flink-connector-1.13.5-2.12-1.0.2-incubating > > - apache-doris-flink-connector-1.14.3-2.12-1.0.2-incubating > > > > > > > > > > This is the first version of flink connector, and 1.0.2 is used because > we have used versions 1.0.0 and 1.0.1 for pre-release before, and these 2 > versions are deprecated. > > We have just moved the code from[1] to [2]. > > > > > > > > > > The release candidates: > > > > > https://dist.apache.org/repos/dist/dev/incubator/doris/flink-connector/1.0.2/ > > > > > > > > > > Maven 2 staging repository: > > > > > https://repository.apache.org/content/repositories/orgapachedoris-1004/org/apache/doris/doris-flink-connector/ > > > > > > > > Git tag for the release: > > > > > https://github.com/apache/incubator-doris-flink-connector/tree/1.11.6-2.12-1.0.2 > > > > > https://github.com/apache/incubator-doris-flink-connector/tree/1.12.7-2.12-1.0.2 > > > > > https://github.com/apache/incubator-doris-flink-connector/tree/1.13.5-2.12-1.0.2 > > > https://github.com/apache/incubator-doris-flink-connector/tree/1.14.3-2.12-1.0.2 > > > > > > > > > > Keys to verify the Release Candidate: > > > > https://downloads.apache.org/incubator/doris/KEYS > > > > > > > > > > Look at here for how to verify this release candidate: > > > > > http://doris.incubator.apache.org/community/release-and-verify/release-verify.html > > > > > > > > > > The vote will be open for at least 72 hours or until necessary number of > votes are reached. > > > > > > > > > > Please vote accordingly: > > > > > > > > > > [ ] +1 approve > > > > [ ] +0 no opinion > > > > [ ] -1 disapprove with the reason > > > > > > > > > > [1] https://github.com/apache/incubator-doris > > > > [2] https://github.com/apache/incubator-doris-flink-connector > > > > > > > > > > -- > > > > 此致！Best Regards > > 陈明雨 Mingyu Chen > > > > Email: > > chenmin...@apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@doris.apache.org > For additional commands, e-mail: dev-h...@doris.apache.org > >
??????[DISCUSS] Weekly build and prepare for releasing 1.0
+1 -- -- ??: "dev"
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
> When a PR labeled with "dev/backlog" is explicitly to be merged into a dev branch, remove the "dev/backlog" label and add the dev label of the corresponding branch. Are you referring to the dev branch as master branch ? So if the PR that does not belong to 1.0 , can it be merged into master directly? Secondly, if a PR belongs to version 1.0. So when merging this PR, do you have to merge it into the master branch and *manually pick *it into the 1.0 branch? Ling Miao 41108453 <41108...@qq.com.invalid> 于2022年2月23日周三 23:54写道： > +1 > > > > > > -- Original -- > From: 陈明雨 Date: Wed,Feb 23,2022 11:44 PM > To: doris-dev Subject: Re: [DISCUSS] Weekly build and prepare for releasing 1.0 > > > > Hi All, > At present, the main features of version 1.0 are in the final stage of > development. Stability and bug fixing work will be carried out later. > We are currently encountering some problems: > 1. some features that have not been fully validated have been merged in, > affecting the testing of existing features, resulting in problems that have > not been converged. > 2. have been unable to maintain a stable baseline version, resulting in > uncontrollable release cycle. > > > In response, I will take the following steps to ensure that the problem is > converged and manageable. > > > 1. PR tagging > All PRs must be labeled with the following tags. > For example, dev-1.0.0 for the first week and dev-1.0.1 > for the second week. > After the branch is created, the branch will only > selectively merge in PRs tagged with "dev/1.0.0". > All subsequent PRs must be labeled as follows. > - dev/1.0.0: Indicates that > this PR needs to be merged into the dev-1.0.0 branch. > - dev/backlog: Indicates that > the PR is not to be merged into any dev branch at this time. > When a PR labeled with "dev/backlog" is explicitly to > be merged into a dev branch, remove the "dev/backlog" label and add the dev > label of the corresponding branch. > > > 2. PR merge principle > After a PR Approve, it should, in principle, stay at > least one day before it is merged in, so that other reviewers can make > possible confirmation. > If you need to merge quickly, please comment in the PR > to explain the reason. > All PRs must have a clear dev label before merging in. > > > The final Release version will be generated from the dev branch. > I will follow up and push for this to happen, if others would like to > participate in this effort, or have suggestions or comments, please feel > free to discuss. > > > > -- > > 此致！Best Regards > 陈明雨 Mingyu Chen > > Email: > chenmin...@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
+1 陈明雨 于2022年2月23日周三 23:44写道： > Hi All, > At present, the main features of version 1.0 are in the final stage of > development. Stability and bug fixing work will be carried out later. > We are currently encountering some problems: > 1. some features that have not been fully validated have been merged in, > affecting the testing of existing features, resulting in problems that have > not been converged. > 2. have been unable to maintain a stable baseline version, resulting in > uncontrollable release cycle. > > > In response, I will take the following steps to ensure that the problem is > converged and manageable. > > > 1. PR tagging > All PRs must be labeled with the following tags. > For example, dev-1.0.0 for the first week and dev-1.0.1 for the second > week. > After the branch is created, the branch will only selectively merge in > PRs tagged with "dev/1.0.0". > All subsequent PRs must be labeled as follows. > - dev/1.0.0: Indicates that this PR needs to be merged into the > dev-1.0.0 branch. > - dev/backlog: Indicates that the PR is not to be merged into any > dev branch at this time. > When a PR labeled with "dev/backlog" is explicitly to be merged into a > dev branch, remove the "dev/backlog" label and add the dev label of the > corresponding branch. > > > 2. PR merge principle > After a PR Approve, it should, in principle, stay at least one day > before it is merged in, so that other reviewers can make possible > confirmation. > If you need to merge quickly, please comment in the PR to explain the > reason. > All PRs must have a clear dev label before merging in. > > > The final Release version will be generated from the dev branch. > I will follow up and push for this to happen, if others would like to > participate in this effort, or have suggestions or comments, please feel > free to discuss. > > > > -- > > 此致！Best Regards > 陈明雨 Mingyu Chen > > Email: > chenmin...@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
+1 寒江雪 于2022年2月24日周四 11:41写道： > +1 > > 陈明雨 于2022年2月23日周三 23:44写道： > > > Hi All, > > At present, the main features of version 1.0 are in the final stage of > > development. Stability and bug fixing work will be carried out later. > > We are currently encountering some problems: > > 1. some features that have not been fully validated have been merged in, > > affecting the testing of existing features, resulting in problems that > have > > not been converged. > > 2. have been unable to maintain a stable baseline version, resulting in > > uncontrollable release cycle. > > > > > > In response, I will take the following steps to ensure that the problem > is > > converged and manageable. > > > > > > 1. PR tagging > > All PRs must be labeled with the following tags. > > For example, dev-1.0.0 for the first week and dev-1.0.1 for the > second > > week. > > After the branch is created, the branch will only selectively merge > in > > PRs tagged with "dev/1.0.0". > > All subsequent PRs must be labeled as follows. > > - dev/1.0.0: Indicates that this PR needs to be merged into the > > dev-1.0.0 branch. > > - dev/backlog: Indicates that the PR is not to be merged into any > > dev branch at this time. > > When a PR labeled with "dev/backlog" is explicitly to be merged into > a > > dev branch, remove the "dev/backlog" label and add the dev label of the > > corresponding branch. > > > > > > 2. PR merge principle > > After a PR Approve, it should, in principle, stay at least one day > > before it is merged in, so that other reviewers can make possible > > confirmation. > > If you need to merge quickly, please comment in the PR to explain the > > reason. > > All PRs must have a clear dev label before merging in. > > > > > > The final Release version will be generated from the dev branch. > > I will follow up and push for this to happen, if others would like to > > participate in this effort, or have suggestions or comments, please feel > > free to discuss. > > > > > > > > -- > > > > 此致！Best Regards > > 陈明雨 Mingyu Chen > > > > Email: > > chenmin...@apache.org > -- 王博 Wang Bo
Re:Re: [VOTE] Release Flink Connectors v1.0.2 for Apache Doris(Incubating)
> 1. We need to add how to build in the README > 2. Need to mention installation of thrift first > 3. We don't need to sign the kit when using mvn clean install by > default, we can add a release profile for signing the kit. OK, we will address them before next release. -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org At 2022-02-24 11:02:54, "Willem Jiang" wrote: >+1. >I checked the License and Notice file >There is no binary in the source release kit. >We have the incubating disclarm in the source file. >I finally built the binary from the source kit in my macbook pro. > >There are some things we can do before the next release. >1. We need to add how to build in the README >2. Need to mention installation of thrift first >3. We don't need to sign the kit when using mvn clean install by >default, we can add a release profile for signing the kit. > >Willem Jiang > >Twitter: willemjiang >Weibo: 姜宁willem > >On Tue, Feb 22, 2022 at 11:43 AM 陈明雨 wrote: >> >> Hi All, >> >> >> >> >> This is a call for vote to release Flink Connectors v1.0.2 for Apache >> Doris(Incubating). >> >> There are 4 outputs for different Flink versions: >> >> >> >> >> - apache-doris-flink-connector-1.11.6-2.12-1.0.2-incubating >> >> - apache-doris-flink-connector-1.12.7-2.12-1.0.2-incubating >> >> - apache-doris-flink-connector-1.13.5-2.12-1.0.2-incubating >> - apache-doris-flink-connector-1.14.3-2.12-1.0.2-incubating >> >> >> >> >> This is the first version of flink connector, and 1.0.2 is used because we >> have used versions 1.0.0 and 1.0.1 for pre-release before, and these 2 >> versions are deprecated. >> We have just moved the code from[1] to [2]. >> >> >> >> >> The release candidates: >> >> https://dist.apache.org/repos/dist/dev/incubator/doris/flink-connector/1.0.2/ >> >> >> >> >> Maven 2 staging repository: >> >> https://repository.apache.org/content/repositories/orgapachedoris-1004/org/apache/doris/doris-flink-connector/ >> >> >> >> Git tag for the release: >> >> https://github.com/apache/incubator-doris-flink-connector/tree/1.11.6-2.12-1.0.2 >> >> https://github.com/apache/incubator-doris-flink-connector/tree/1.12.7-2.12-1.0.2 >> >> https://github.com/apache/incubator-doris-flink-connector/tree/1.13.5-2.12-1.0.2 >> https://github.com/apache/incubator-doris-flink-connector/tree/1.14.3-2.12-1.0.2 >> >> >> >> >> Keys to verify the Release Candidate: >> >> https://downloads.apache.org/incubator/doris/KEYS >> >> >> >> >> Look at here for how to verify this release candidate: >> >> http://doris.incubator.apache.org/community/release-and-verify/release-verify.html >> >> >> >> >> The vote will be open for at least 72 hours or until necessary number of >> votes are reached. >> >> >> >> >> Please vote accordingly: >> >> >> >> >> [ ] +1 approve >> >> [ ] +0 no opinion >> >> [ ] -1 disapprove with the reason >> >> >> >> >> [1] https://github.com/apache/incubator-doris >> >> [2] https://github.com/apache/incubator-doris-flink-connector >> >> >> >> >> -- >> >> 此致！Best Regards >> 陈明雨 Mingyu Chen >> >> Email: >> chenmin...@apache.org > >- >To unsubscribe, e-mail: dev-unsubscr...@doris.apache.org >For additional commands, e-mail: dev-h...@doris.apache.org
Re:Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Let me re-state the complete process. For example, if we are currently ready to release 1.0, I would create a dev branch with a name such as dev-1.0.x. For example, I would create the first branch, dev-1.0.0, and create the corresponding labels: dev/1.0.0, dev/backlog, and dev/merged. All new commits are still committed to the master branch as before, and then merged into master after review-approved, but when merged, they must be tagged with the corresponding dev label, such as dev/1.0.0 or dev/backlog, where dev/1.0.0 means the PR needs to be merged into the dev-1.0.0 branch, and dev/backlog means the PR is not merged into the dev-1.0.x branch. So, all commits will still be merged into the master branch, as usual. And we need to do the following additional things: 1. every day, we filter out the commits that correspond to the label of the current dev branch (e.g. dev-1.0.0). after multiple people confirm that these commits are to be merged into dev-1.0.0, the designated person will manually merge these commits into dev-1.0.0. after merging, we need to label these PRs dev/merged. 2. The purpose of the dev branch is to "isolate unintended code risks". For example, if the first week we focus on fixing bugs in the join operator, then the first week of dev-1.0.0 may only accept join-related bug fixes. In the second week, when the join issue is fixed, the dev-1.0.1 branch will be created and will start accepting commits that were previously tagged as backlog. At this point, you need to remove the backlog tag from the PR and add the tag of dev/1.0.1. 3. for example, at dev-1.0.3, we think we are ready to release, so we will do a release based on this branch. 4. Assuming that the next release is 1.1, we might create branch dev-1.1.0 directly from the latest master branch, which would include all the previous commits that were not merged into 1.0, and then repeat the previous operation. === 让我重新说明下完整的流程： 比如我们当前准备发布 1.0 版本了，那么我会创建 dev 分支。dev 分支的命名规则如：dev-1.0.x。比如我会创建第一个分支 dev-1.0.0，并且会创建相应的 label：dev/1.0.0，dev/backlog 和 dev/merged 所有的新提交依然和以前一样提交到 master 分支，经过review-approve后合入master。但合入时，必须打上对应的dev标签，如dev/1.0.0 或 dev/backlog。其中dev/1.0.0 表示该PR需要合并到 dev-1.0.0分支中。而dev/backlog 则表示该PR不合入到 dev-1.0.x 分支中。 所以，所有提交依然会和往常一样，全部合入master分支。而我们需要额外做如下事情： 1. 每天筛选出当前dev分支（比如dev-1.0.0）对应标签的commit。经多人确认这些commit要合入dev-1.0.0后，由指定人选手动将这些commit合入dev-1.0.0，合入后，需要给这些PR打上标签 dev/merged 2. dev 分支的作用在于“隔离预期外的代码风险”。比如第一周我们重点在修复join算子的bug，那么第一周的 dev-1.0.0 版本可能只接受join相关的bug修复。其他的commit都会标记为 backlog。而第二周join问题修复完成了，可能会创建dev-1.0.1分支，开始接收之前标记为backlog的commit。此时，需要将PR的backlog标签删除并增加 dev/1.0.1 的标签。 3. 比如到 dev-1.0.3 时，我们认为具备发版条件了，那么会基于 这个分支进行release。 4. 假设接下来发布 1.1 版本，那可能会直接从最新 master 分支创建branch dev-1.1.0，这样相当于包含了之前所有未合入到 1.0 版本的commit，然后重复之前的操作。 -- 此致！Best Regards 陈明雨 Mingyu Chen Email: chenmin...@apache.org 在 2022-02-24 11:14:48，"ling miao" 写道： >> When a PR labeled with "dev/backlog" is explicitly to be merged into >a dev branch, remove the "dev/backlog" label and add the dev label of the >corresponding branch. > >Are you referring to the dev branch as master branch ? >So if the PR that does not belong to 1.0 , can it be merged into master >directly? > >Secondly, if a PR belongs to version 1.0. >So when merging this PR, do you have to merge it into the master >branch and *manually >pick *it into the 1.0 branch? > >Ling Miao > >41108453 <41108...@qq.com.invalid> 于2022年2月23日周三 23:54写道： > >> +1 >> >> >> >> >> >> -- Original -- >> From: 陈明雨 > Date: Wed,Feb 23,2022 11:44 PM >> To: doris-dev > Subject: Re: [DISCUSS] Weekly build and prepare for releasing 1.0 >> >> >> >> Hi All, >> At present, the main features of version 1.0 are in the final stage of >> development. Stability and bug fixing work will be carried out later. >> We are currently encountering some problems: >> 1. some features that have not been fully validated have been merged in, >> affecting the testing of existing features, resulting in problems that have >> not been converged. >> 2. have been unable to maintain a stable baseline version, resulting in >> uncontrollable release cycle. >> >> >> In response, I will take the following steps to ensure that the problem is >> converged and manageable. >> >> >> 1. PR tagging >> All PRs must be labeled with the following tags. >> For example, dev-1.0.0 for the first week and dev-1.0.1 >> for the second week. >> After the branch is created, the branch will only >> selectively merge in PRs tagged with "dev/1.0.0". >> All subsequent PRs must be labeled as follows. >> - dev/1.0.0: Indicates that >> this PR needs to be merged into the dev-1.0.0 branch. >> - dev/backlog: Indicates that >> the PR is not to be merged into any dev branch at this time. >> When a PR labeled with "dev/backlog" is explicitly to >> be merged into a dev branch, remove the "dev/backlog" label and add the dev >> label of the corres
