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* >
