+1 On Wed 1 May, 2019, 1:13 AM Sijie Guo, <guosi...@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 <uvar...@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 <guosi...@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 <uvar...@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 <guosi...@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* > > >
