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 <eolive...@gmail.com> wrote: > Il ven 11 ago 2017, 04:15 Sijie Guo <guosi...@gmail.com> ha scritto: > > > On Thu, Aug 10, 2017 at 6:48 PM, Jia Zhai <zhaiji...@gmail.com> 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 <guosi...@gmail.com> 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 >
