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" <coding...@apache.org>: 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
