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)?
> 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
> > 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`.
> > - 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`.
> > - if a change is a bug fix that needs to be included in a bug fix
> > it will be labelled with that release.
> > *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`
> > `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,
> > that we are able to know what changes are included in which release.
> > How does this sound? Any thoughts?
> > - Sijie