Thank you. Good idea I hope I will be able to use it soon Enrico
Il ven 11 ago 2017, 13:45 Jia Zhai <zhaiji...@gmail.com> 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 <guosi...@gmail.com> 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 <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 > > > > > > -- -- Enrico Olivelli
