+1
On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <[email protected]> wrote: > Hello Nan, > > Good suggestion! > > "hotfix which brings the broken build back to track" nitpicking, but I > wouldn't consider this a tiny fix. There should also be a jira that > reported the build being broken, so that shouldn't be a problem to link. > > Very good idea with the automated script! > > How would we handle permissions? Which actions are non-committers able to > execute and in which cases would a committer be required? > > How would we treat GitHub issues in future? As a board for users to ask > usage questions? > > In order to improve user experience for new developers, I'd like to suggest > that more experienced people might create jira tickets on behalf of others > instead of telling them "please create a ticket". I think we all made the > experience with people from it department who blocked every request until a > ticket was created and assigned :P > > Best regards, > Marco > > Am 23.02.2018 6:07 nachm. schrieb "CodingCat" <[email protected]>: > > Hi, all > > To make the changes in code base more trackable, > > I would propose to link each PR with the a JIRA from now on: > > 1. most of PRs should be titled as [MXNET-???][MODULE_NAME] PR short > description, where MXNET-??? is the JIRA ID, MODULE_NAME can be python, > scala, symbol, etc. > > 2. only the very tiny fix, e.g. fix a typo, remove some unused variables, > or the hotfix which brings the broken build back to track, can be filed > without JIRA ID in title, > > In JIRA side, to link the issue with an arrived PR, we can run a script > like https://github.com/apache/spark/blob/master/dev/github_jira_sync.py > to > update JIRA status (can be run in Jenkins) > > > The benefits of applying such a flow include (but not limited to) > > 1. facilitate the release process: > > e.g., as long as tagging each JIRA with the correct affected version and > fixed version, the release manager can quickly identify what are the > changes applied in this version; or we can quickly identify whether there > is any blocker issue in the JIRA > > 2. trackable changes > > any changes in MXNET can be quickly searched through JIRA or even through > Google (JIRA looks like did something makes it more indexable by Google), > > > If the vote gets pass, the plan in the near horizon includes > > 1. update JIRA with the modules names > > 2. write runbook for release manager/committer for releasing new > version/merging patches, as well as contributors about the usage of JIRA > > 3. push the changes to the existing and coming PRs (this also needs the > collaboration across the whole committer team) > > The vote will end at 12:00 p.m. of March 2nd, 2018 > > Best, > > Nan >
