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 >> >
