Okay. Let's try this to see if it help us. I am going to merge https://github.com/apache/bookkeeper/pull/437 so committers can start use it on merging pull requests.
Please provide any feedback on this tool. We can together improve the tool. - Sijie On Fri, Aug 11, 2017 at 4:55 AM, Enrico Olivelli <[email protected]> wrote: > Thank you. Good idea > I hope I will be able to use it soon > > Enrico > > Il ven 11 ago 2017, 13:45 Jia Zhai <[email protected]> ha scritto: > > > Since it may not easy to change the permissions for contributor, This PR > is > > a good alternative to make it easy. Thanks a lot to make it happen. > > > > On Fri, Aug 11, 2017 at 7:07 PM, Sijie Guo <[email protected]> wrote: > > > > > I've played around github API and come up a change to the merge script. > > It > > > handles adding milestone, labels (area, type and release) when merging > > pull > > > requests. If a change is cherry-pick to a branch for bug fixes, a bug > fix > > > release is required to add as well. > > > > > > this is the pull request - https://github.com/apache/ > bookkeeper/pull/437 > > > > > > I actually just used this script merged #424 > > > <https://github.com/apache/bookkeeper/pull/424> . This script would > then > > > instruct the committer to choose milestone, labels(area/type/release) > on > > > merging. Both the issue and the pull request were updated with same > > > milestone, labels. So > > > > > > Example output: > > > > > > ------------------------ > > > > > > *Choose fix milestone : options are [4.6.0] - default: [4.6.0]:* > > > *Choose label 'area/' - options are: [bookie, build, client, docker, > > > documentation, metadata, protocol, release, security, tests] - default: > > > [bookie, tests] (comma separated):* > > > *Choose label 'type/' - options are: [bug, feature, task] - default: > > [bug] > > > (comma separated):* > > > *=== Apply following milestone, area, type to github issues ==* > > > *Fix Types: bug* > > > *Fix Areas: bookie, tests* > > > *Fix Milestone: 4.6.0* > > > > > > *Would you like to update github issues with these labels? (y/n): y* > > > > > > > > > *-----------------------------* > > > > > > Any thoughts? > > > > > > - Sijie > > > > > > On Thu, Aug 10, 2017 at 11:12 PM, Enrico Olivelli <[email protected] > > > > > wrote: > > > > > > > Il ven 11 ago 2017, 04:15 Sijie Guo <[email protected]> ha scritto: > > > > > > > > > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <[email protected]> > > wrote: > > > > > > > > > > > The work flow sounds great. > > > > > > Currently, One problem is that contributor do not have > permissions > > to > > > > > > change the Assignees, Labels, projects and Milestone for both > issue > > > and > > > > > > PR. It would be better if contributor could do that. > > > > > > > > > > > > > > > > I am not sure how to configure that. Is there any settings on > github > > > that > > > > > we can configure (or ask INFRA to configure)? > > > > > > > > > > - Sijie > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 11, 2017 at 8:42 AM, Sijie Guo <[email protected]> > > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > Currently we are using Milestone for feature release on Github. > > > > However > > > > > > it > > > > > > > will become difficult on doing bug releases, because an issue > can > > > > only > > > > > be > > > > > > > assigned to one milestone. So I am proposing: > > > > > > > > > > > > > > - add labels for `release/x.y.z` for a given release. for > > example, > > > if > > > > > we > > > > > > > need to 4.5.1 release, we create a label `release/4.5.1`. > > > > > > > > > Ok > > > > > > > > > > > - for any change, it would go to master first anyway. this > change > > > > will > > > > > be > > > > > > > associated with current feature release (for example, 4.6.0) > and > > > > > labelled > > > > > > > with `release/4.6.0`. > > > > > > > > > Ok > > > > > > > > > > > - if a change is a bug fix that needs to be included in a bug > fix > > > > > > release, > > > > > > > it will be labelled with that release. > > > > > > > > > Ok > > > > > > > > > > > > > > > > > > *How does this flow work?* > > > > > > > > > > > > > > Let's use an example: contributor A and committer B. > > > > > > > > > > > > > > - Contributor A finds a bug for 4.5.0. He files a Github issue > > and > > > > > send a > > > > > > > pull request for this fix. He can assign milestone 4.6.0 (which > > is > > > > the > > > > > > > current feature release) to this issue and label it as > > > > `release/4.6.0` > > > > > > and > > > > > > > `release/4.5.1`. A doesn't have to assign milestone and labels > if > > > he > > > > > > > doesn't know how to do that. > > > > > > > > > > > > > > - The pull request is reviewed and approved. Committer B would > > use > > > > > merge > > > > > > > script to merge this pull request. Committer B would follow the > > > > > > > instructions in the merge script to fill the labels, assign > > > releases. > > > > > > > > > > > > > > - The actual milestone and labels can be updated with the merge > > > > script, > > > > > > so > > > > > > > that we are able to know what changes are included in which > > > release. > > > > > > > > > > > > > > How does this sound? Any thoughts? > > > > > > > > > > > > > We can try. It could work. I did not see this workflow in othet > > projects > > > > but I have limited experience of complex github projects > > > > > > > > +1 > > > > > > > > Enrico > > > > > > > > > > > > > > > > > - Sijie > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > -- Enrico Olivelli > > > > > > > > > > -- > > > -- Enrico Olivelli >
