You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pulsar.apache.org by Yuva raj <uv...@gmail.com> on 2019/04/01 07:49:24 UTC
Re: Major and Minor Release Management
Hi Sijie,
Are we going to do this for 2.3.1 release ? We need 2 of our pull request
#3956 and #3840 to be merged in 2.3.1. If required we can go ahead and
request to add cherry-pick/2.3.1
On Thu, 21 Feb 2019 at 23:35, Sijie Guo <gu...@gmail.com> wrote:
> On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly <iv...@apache.org> wrote:
>
> > > If so, I would suggest pulling the proposal out of the thread and do a
> > vote
> > > to make sure everyone in the community are on the same page.
> > >
> > > It is okay we don't have to document at this time. We can let you
> manage
> > > the process in next bugfix release. Once it is done, propagate the
> > process
> > > to Pulsar website and finalize it.
> >
> > Are you suggesting doing a vote now? or after we go through the
> > process one time?
> >
>
> I was suggesting doing a vote first. because I would like to fix the state
> first. so the committers won't be merging pull requests to master but
> labelling them for minor releases.
>
> Vote is for the community to agree on a direction. If we agree on the
> direction, you can run the process one time and document the details about
> cherry-picks for other committers to follow.
>
>
> >
> > -Ivan
> >
>
--
*Thanks*
*Yuvaraj L*
Re: Major and Minor Release Management
Posted by Yuva raj <uv...@gmail.com>.
+1
On Wed 1 May, 2019, 1:13 AM Sijie Guo, <gu...@gmail.com> wrote:
> Agreed. We should seriously consider introducing a process for managing
> this minor release.
>
> Also I am re-proposing using the approach we used in bookkeeper to have a
> merge script to merge and cherry-pick the changes.
> The script that bookkeeper uses comes from Spark and the same approach has
> been adopted by many ASF projects like
> Kafka, Spark, Flink and many other big data projects.
>
> - Spark: https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
> - Kafka: https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> - BookKeeper:
> https://github.com/apache/bookkeeper/blob/master/dev/bk-merge-pr.py
> - Flink:
> https://github.com/apache/flink/blob/master/tools/merge_flink_pr.py
>
> One of the reasons I like the merge script approach is it deals with
> cherry-picks at the time when a change is merged
> to master. Because the people who merges the PR are usually also the PR
> reviewers. Hence he has the best fresh view on the
> code changes and understands the code at that moment so he can have the
> best idea to address the conflicts when he
> cherry-picks the change to a branch. If he is not able to cherry-pick the
> change, he can also ask the original author for helps.
>
> If we defer all the cherry-picks to the release manager at a much later
> stage, release manager has to spend time to understand
> the changes to make a right cherry-pick. The possibility of missing
> changes during cherry-picks increased. For example, in the
> issue I dealt with today (#4181), one cherry-pick drops one line change,
> because there is a refactor around schema compatibility
> checker and the file was renamed.
>
> Anyway, I am looking forward to see how other people think about this.
>
> - Sijie
>
> On Tue, Apr 30, 2019 at 8:57 PM Yuva raj <uv...@gmail.com> wrote:
>
> > Hi all,
> > Considering that we are facing issues in minor releases
> *ex:*
> > https://github.com/apache/pulsar/issues/4095
> > https://github.com/apache/pulsar/pull/4181 It would be great if we
> > introduce a process to keep track of commits to be merged into minor
> > versions . On top it releases manager always has a control on cherry
> > picking?
> >
> > On Mon, 1 Apr 2019 at 23:15, Sijie Guo <gu...@gmail.com> wrote:
> >
> > > Hi Yuva,
> > >
> > > I don't think we have adopted this process. Matteo is driving 2.3.1
> > > release.
> > >
> > > #3840 is already marked for 2.3.1.
> > >
> > > I also comment in #3956 and mark it for 2.3.1.
> > >
> > > - Sijie
> > >
> > > On Mon, Apr 1, 2019 at 12:49 AM Yuva raj <uv...@gmail.com> wrote:
> > >
> > > > Hi Sijie,
> > > > Are we going to do this for 2.3.1 release ? We need 2 of our pull
> > request
> > > > #3956 and #3840 to be merged in 2.3.1. If required we can go ahead
> > and
> > > > request to add cherry-pick/2.3.1
> > > >
> > > > On Thu, 21 Feb 2019 at 23:35, Sijie Guo <gu...@gmail.com> wrote:
> > > >
> > > > > On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly <iv...@apache.org>
> wrote:
> > > > >
> > > > > > > If so, I would suggest pulling the proposal out of the thread
> and
> > > do
> > > > a
> > > > > > vote
> > > > > > > to make sure everyone in the community are on the same page.
> > > > > > >
> > > > > > > It is okay we don't have to document at this time. We can let
> you
> > > > > manage
> > > > > > > the process in next bugfix release. Once it is done, propagate
> > the
> > > > > > process
> > > > > > > to Pulsar website and finalize it.
> > > > > >
> > > > > > Are you suggesting doing a vote now? or after we go through the
> > > > > > process one time?
> > > > > >
> > > > >
> > > > > I was suggesting doing a vote first. because I would like to fix
> the
> > > > state
> > > > > first. so the committers won't be merging pull requests to master
> but
> > > > > labelling them for minor releases.
> > > > >
> > > > > Vote is for the community to agree on a direction. If we agree on
> the
> > > > > direction, you can run the process one time and document the
> details
> > > > about
> > > > > cherry-picks for other committers to follow.
> > > > >
> > > > >
> > > > > >
> > > > > > -Ivan
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > *Thanks*
> > > >
> > > > *Yuvaraj L*
> > > >
> > >
> >
> >
> > --
> > *Thanks*
> >
> > *Yuvaraj L*
> >
>
Re: Major and Minor Release Management
Posted by Sijie Guo <gu...@gmail.com>.
Agreed. We should seriously consider introducing a process for managing
this minor release.
Also I am re-proposing using the approach we used in bookkeeper to have a
merge script to merge and cherry-pick the changes.
The script that bookkeeper uses comes from Spark and the same approach has
been adopted by many ASF projects like
Kafka, Spark, Flink and many other big data projects.
- Spark: https://github.com/apache/spark/blob/master/dev/merge_spark_pr.py
- Kafka: https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
- BookKeeper:
https://github.com/apache/bookkeeper/blob/master/dev/bk-merge-pr.py
- Flink: https://github.com/apache/flink/blob/master/tools/merge_flink_pr.py
One of the reasons I like the merge script approach is it deals with
cherry-picks at the time when a change is merged
to master. Because the people who merges the PR are usually also the PR
reviewers. Hence he has the best fresh view on the
code changes and understands the code at that moment so he can have the
best idea to address the conflicts when he
cherry-picks the change to a branch. If he is not able to cherry-pick the
change, he can also ask the original author for helps.
If we defer all the cherry-picks to the release manager at a much later
stage, release manager has to spend time to understand
the changes to make a right cherry-pick. The possibility of missing
changes during cherry-picks increased. For example, in the
issue I dealt with today (#4181), one cherry-pick drops one line change,
because there is a refactor around schema compatibility
checker and the file was renamed.
Anyway, I am looking forward to see how other people think about this.
- Sijie
On Tue, Apr 30, 2019 at 8:57 PM Yuva raj <uv...@gmail.com> wrote:
> Hi all,
> Considering that we are facing issues in minor releases *ex:*
> https://github.com/apache/pulsar/issues/4095
> https://github.com/apache/pulsar/pull/4181 It would be great if we
> introduce a process to keep track of commits to be merged into minor
> versions . On top it releases manager always has a control on cherry
> picking?
>
> On Mon, 1 Apr 2019 at 23:15, Sijie Guo <gu...@gmail.com> wrote:
>
> > Hi Yuva,
> >
> > I don't think we have adopted this process. Matteo is driving 2.3.1
> > release.
> >
> > #3840 is already marked for 2.3.1.
> >
> > I also comment in #3956 and mark it for 2.3.1.
> >
> > - Sijie
> >
> > On Mon, Apr 1, 2019 at 12:49 AM Yuva raj <uv...@gmail.com> wrote:
> >
> > > Hi Sijie,
> > > Are we going to do this for 2.3.1 release ? We need 2 of our pull
> request
> > > #3956 and #3840 to be merged in 2.3.1. If required we can go ahead
> and
> > > request to add cherry-pick/2.3.1
> > >
> > > On Thu, 21 Feb 2019 at 23:35, Sijie Guo <gu...@gmail.com> wrote:
> > >
> > > > On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly <iv...@apache.org> wrote:
> > > >
> > > > > > If so, I would suggest pulling the proposal out of the thread and
> > do
> > > a
> > > > > vote
> > > > > > to make sure everyone in the community are on the same page.
> > > > > >
> > > > > > It is okay we don't have to document at this time. We can let you
> > > > manage
> > > > > > the process in next bugfix release. Once it is done, propagate
> the
> > > > > process
> > > > > > to Pulsar website and finalize it.
> > > > >
> > > > > Are you suggesting doing a vote now? or after we go through the
> > > > > process one time?
> > > > >
> > > >
> > > > I was suggesting doing a vote first. because I would like to fix the
> > > state
> > > > first. so the committers won't be merging pull requests to master but
> > > > labelling them for minor releases.
> > > >
> > > > Vote is for the community to agree on a direction. If we agree on the
> > > > direction, you can run the process one time and document the details
> > > about
> > > > cherry-picks for other committers to follow.
> > > >
> > > >
> > > > >
> > > > > -Ivan
> > > > >
> > > >
> > >
> > >
> > > --
> > > *Thanks*
> > >
> > > *Yuvaraj L*
> > >
> >
>
>
> --
> *Thanks*
>
> *Yuvaraj L*
>
Re: Major and Minor Release Management
Posted by Yuva raj <uv...@gmail.com>.
Hi all,
Considering that we are facing issues in minor releases *ex:*
https://github.com/apache/pulsar/issues/4095
https://github.com/apache/pulsar/pull/4181 It would be great if we
introduce a process to keep track of commits to be merged into minor
versions . On top it releases manager always has a control on cherry
picking?
On Mon, 1 Apr 2019 at 23:15, Sijie Guo <gu...@gmail.com> wrote:
> Hi Yuva,
>
> I don't think we have adopted this process. Matteo is driving 2.3.1
> release.
>
> #3840 is already marked for 2.3.1.
>
> I also comment in #3956 and mark it for 2.3.1.
>
> - Sijie
>
> On Mon, Apr 1, 2019 at 12:49 AM Yuva raj <uv...@gmail.com> wrote:
>
> > Hi Sijie,
> > Are we going to do this for 2.3.1 release ? We need 2 of our pull request
> > #3956 and #3840 to be merged in 2.3.1. If required we can go ahead and
> > request to add cherry-pick/2.3.1
> >
> > On Thu, 21 Feb 2019 at 23:35, Sijie Guo <gu...@gmail.com> wrote:
> >
> > > On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly <iv...@apache.org> wrote:
> > >
> > > > > If so, I would suggest pulling the proposal out of the thread and
> do
> > a
> > > > vote
> > > > > to make sure everyone in the community are on the same page.
> > > > >
> > > > > It is okay we don't have to document at this time. We can let you
> > > manage
> > > > > the process in next bugfix release. Once it is done, propagate the
> > > > process
> > > > > to Pulsar website and finalize it.
> > > >
> > > > Are you suggesting doing a vote now? or after we go through the
> > > > process one time?
> > > >
> > >
> > > I was suggesting doing a vote first. because I would like to fix the
> > state
> > > first. so the committers won't be merging pull requests to master but
> > > labelling them for minor releases.
> > >
> > > Vote is for the community to agree on a direction. If we agree on the
> > > direction, you can run the process one time and document the details
> > about
> > > cherry-picks for other committers to follow.
> > >
> > >
> > > >
> > > > -Ivan
> > > >
> > >
> >
> >
> > --
> > *Thanks*
> >
> > *Yuvaraj L*
> >
>
--
*Thanks*
*Yuvaraj L*
Re: Major and Minor Release Management
Posted by Sijie Guo <gu...@gmail.com>.
Hi Yuva,
I don't think we have adopted this process. Matteo is driving 2.3.1
release.
#3840 is already marked for 2.3.1.
I also comment in #3956 and mark it for 2.3.1.
- Sijie
On Mon, Apr 1, 2019 at 12:49 AM Yuva raj <uv...@gmail.com> wrote:
> Hi Sijie,
> Are we going to do this for 2.3.1 release ? We need 2 of our pull request
> #3956 and #3840 to be merged in 2.3.1. If required we can go ahead and
> request to add cherry-pick/2.3.1
>
> On Thu, 21 Feb 2019 at 23:35, Sijie Guo <gu...@gmail.com> wrote:
>
> > On Thu, Feb 21, 2019 at 8:03 PM Ivan Kelly <iv...@apache.org> wrote:
> >
> > > > If so, I would suggest pulling the proposal out of the thread and do
> a
> > > vote
> > > > to make sure everyone in the community are on the same page.
> > > >
> > > > It is okay we don't have to document at this time. We can let you
> > manage
> > > > the process in next bugfix release. Once it is done, propagate the
> > > process
> > > > to Pulsar website and finalize it.
> > >
> > > Are you suggesting doing a vote now? or after we go through the
> > > process one time?
> > >
> >
> > I was suggesting doing a vote first. because I would like to fix the
> state
> > first. so the committers won't be merging pull requests to master but
> > labelling them for minor releases.
> >
> > Vote is for the community to agree on a direction. If we agree on the
> > direction, you can run the process one time and document the details
> about
> > cherry-picks for other committers to follow.
> >
> >
> > >
> > > -Ivan
> > >
> >
>
>
> --
> *Thanks*
>
> *Yuvaraj L*
>