My motivation is simple - I would like to see a process for managing merging pull requests, add labels and milestone and cherry-picks for releases. Otherwise things just become very messy with different people merging pull requests in different ways.
I know there was a discussion about the merge script. but people doesn't like the way how bk merge script closes the pull request. http://mail-archives.apache.org/mod_mbox/pulsar-dev/201708.mbox/%3CCAGjw%2BkO1ucxp%3DKn0aK077kANhiZiVRcL5exhPJPgHkdfa7XSCA%40mail.gmail.com%3E So I changed the merge script to use github pull request merge api on merging a PR. here is the script: https://github.com/apache/incubator-pulsar/pull/2526 This is one example PR how it was merged by the script: https://github.com/sijie/incubator-pulsar/pull/8 Let me know what do you think. - Sijie On Mon, Aug 27, 2018 at 2:45 AM Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > I think we need to discuss how to label the issues and how to cherry-pick > the issues for bug fixes. Currently it is painful for doing a bugfix > release. > All the bug fixes are deferred to release manager cherry-picking to bug > fix branches. Since master and branches are quickly diverged with changes, > it is very painful for cherry-picks later and there is no clear process > for cherry-pick and labelling. > > Shall we consider following the process what BookKeeper is using, having a > merge script to handle labelling issues/milestones and also cherry-picks? > > Or any suggestions on how to improve this? > > - Sijie > > On Mon, Aug 6, 2018 at 10:50 AM Sijie Guo <guosi...@gmail.com> wrote: > >> Hi all, >> >> It seems we don't have a standard for labelling milestone. sometimes I am >> not lost and confused when I see a change was merged to master but marked >> in a bug fix milestone. so I am raising a discussion about this. >> >> I think every pull request that was created based on master, which would >> be merged as a commit of master, those pull requests should be first marked >> as major release milestone, for example: `2.2.0` release. If a pull request >> that was created based on a branch, which would be merged as a commit of >> that branch, those pull requests should be marked as minor release >> milestones, for example: `2.1.1` release. so that we have a clearer way on >> tracking what changes have been made to what releases. otherwise it is a >> bit hard to track when we have multiple releases ongoing. >> >> Thoughts? >> >> Thanks, >> Sijie >> >>
