All projects on Apache have Jira <---> Github integration in place. So its a solved problem - look at Flink, Kafka, Mahout, OpenNLP, PredictionIO and every other Apache project - all of them have this working.
On Tue, Feb 27, 2018 at 8:35 PM, Steffen Rochel <[email protected]> wrote: > Nan - have you looked at plugin's to make the integration and > synchronization between Jira and github easier? E.g. > https://www.atlassian.com/blog/jira-software/connecting-jira-6-2-github f > Ideally one has one button in github to create a Jira and afterwards > changes on either github or Jira get synchronized. > What tools is ASF infra recommending? > Have you used > https://github.com/apache/spark/blob/master/dev/github_jira_sync.py and > what is the recommended use case? How do get github issues updated from > Jira? > > Steffen > > On Tue, Feb 27, 2018 at 10:31 AM Indhu <[email protected]> wrote: > > > +1 to the proposal > > > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <[email protected]> wrote: > > > > > 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 > > > > >> > > > > > > > > > > > > > > >
