ideally, users report something fishy in github issue
when confirmed that it is a bug or something to be improved, we should create JIRAs On Sun, Feb 25, 2018 at 9:31 AM, Chris Olivier <[email protected]> wrote: > i believe that JIRAs are “work items@, while github issues are more like > reporting. at least this is what Infra sort of claimed. > > On Sun, Feb 25, 2018 at 9:30 AM Chris Olivier <[email protected]> > wrote: > > > +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 > >> > > >
