You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@doris.apache.org by 陈明雨 <mo...@163.com> on 2022/02/23 15:44:18 UTC
[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:
chenmingyu@apache.org
Re:[DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 陈明雨 <mo...@163.com>.
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:
chenmingyu@apache.org
At 2022-02-23 23:44:18, "陈明雨" <mo...@163.com> 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:
>chenmingyu@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 王博 <wa...@gmail.com>.
+1
寒江雪 <ya...@gmail.com> 于2022年2月24日周四 11:41写道：
> +1
>
> 陈明雨 <mo...@163.com> 于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:
> > chenmingyu@apache.org
>
--
王博 Wang Bo
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 寒江雪 <ya...@gmail.com>.
+1
陈明雨 <mo...@163.com> 于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:
> chenmingyu@apache.org
回复：[DISCUSS] Weekly build and prepare for releasing 1.0
Posted by luzhijing <54...@qq.com.INVALID>.
+1
------------------ 原始邮件 ------------------
发件人: "dev" <morningman@163.com>;
发送时间: 2022年2月23日(星期三) 晚上11:44
收件人: "doris-dev"<dev@doris.apache.org>;
主题: [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:
chenmingyu@apache.org
Re:Re:Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 陈明雨 <mo...@163.com>.
Hi all:
The current dev-1.0.0 branch has passed regression testing.
Currently remaining PRs and Issues to be merged:
* https://github.com/apache/incubator-doris/labels/dev%2F1.0.0
The new branch dev-1.0.1 will be created.
And the labels for dev/1.0.0 and dev/merged-1.0.0 will no longer be used, use dev/1.0.1 and dev/merged-1.0.1 instead
All backlog commits can be found here:
* https://github.com/apache/incubator-doris/pulls?q=is%3Apr+is%3Aopen+label%3Adev%2Fbacklog
Some of them will be cherry-picked into branch dev-1.0.1
--
此致！Best Regards
陈明雨 Mingyu Chen
Email:
chenmingyu@apache.org
At 2022-02-24 13:09:37, "陈明雨" <mo...@163.com> wrote:
>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:
>chenmingyu@apache.org
>
>
>
>
>
>在 2022-02-24 11:14:48，"ling miao" <li...@apache.org> 写道：
>>> 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 <41...@qq.com.invalid> 于2022年2月23日周三 23:54写道：
>>
>>> +1
>>>
>>>
>>>
>>>
>>>
>>> ------------------ Original ------------------
>>> From: 陈明雨 <morningman@163.com>
>>> Date: Wed,Feb 23,2022 11:44 PM
>>> To: doris-dev <dev@doris.apache.org>
>>> 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:
>>> chenmingyu@apache.org
Re:Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 陈明雨 <mo...@163.com>.
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:
chenmingyu@apache.org
在 2022-02-24 11:14:48，"ling miao" <li...@apache.org> 写道：
>> 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 <41...@qq.com.invalid> 于2022年2月23日周三 23:54写道：
>
>> +1
>>
>>
>>
>>
>>
>> ------------------ Original ------------------
>> From: 陈明雨 <morningman@163.com>
>> Date: Wed,Feb 23,2022 11:44 PM
>> To: doris-dev <dev@doris.apache.org>
>> 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:
>> chenmingyu@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by ling miao <li...@apache.org>.
> 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 <41...@qq.com.invalid> 于2022年2月23日周三 23:54写道：
> +1
>
>
>
>
>
> ------------------ Original ------------------
> From: 陈明雨 <morningman@163.com>
> Date: Wed,Feb 23,2022 11:44 PM
> To: doris-dev <dev@doris.apache.org>
> 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:
> chenmingyu@apache.org
Re: [DISCUSS] Weekly build and prepare for releasing 1.0
Posted by 41108453 <41...@qq.com.INVALID>.
+1
------------------ Original ------------------
From: 陈明雨 <morningman@163.com>
Date: Wed,Feb 23,2022 11:44 PM
To: doris-dev <dev@doris.apache.org>
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:
chenmingyu@apache.org