I don't think the [MODULE NAME] is feasible. A modification in the backend often requires changes in multiple interface languages. I think we should rather tag the JIRA issues properly.
But since this is a minor detail, I'll +1 considering the time running out. -Marco On Tue, Feb 27, 2018 at 11:34 PM, Yuan Tang <terrytangy...@gmail.com> wrote: > +1 > > On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <smar...@apache.org> wrote: > > > On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zhunanmcg...@gmail.com> > wrote: > > > > > > Any reason u need the [MODULE_NAME] in there > > > > > > It will help the reviewers to identify what are the interesting PRs to > > them > > > > > > e.g. I am interested in scala package, but > > > https://github.com/apache/incubator-mxnet/pull/9771, even with a JIRA > > id, > > > cannot help me to identify it's a scala part change I may be interested > > in > > > > > > > Well,, yeah maybe ... the JIRA would be labeled as Scala API anyways - so > > still thinking this may not be needed - i am fine either ways. > > > > > > > > > What ??? elaborate please?? > > > > > > we do not need additional engineering efforts to implement sync > > > > > > the only thing is to get this vote passed, and all committers do not > > merge > > > the PRs unless there is a JIRA (except the situations in 2) > > > > > > > > No, u don't, sync is taken care of by Infra. Here's my +1 binding > > > > > > > > > > > On Tue, Feb 27, 2018 at 2:13 PM, Suneel Marthi <smar...@apache.org> > > wrote: > > > > > > > On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zhunanmcg...@gmail.com> > > > wrote: > > > > > > > > > Thanks, Suneel! > > > > > > > > > > the vote still remains sense on its major points > > > > > > > > > > " > > > > > 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. > > > > > > > > > > > > > Any reason u need the [MODULE_NAME] in there - I would -1 that > > > > > > > > [MXNET-XYZ] is unique enuf to identify the specific module - not to > > > mention > > > > that the different modules can be setup to label each jira - so > > > > [MODULE-blah] is unnecessary. > > > > > > > > > > > > > 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, > > > > > > > > > > > > > Agreed - and in this case the convention has been to use [NO-JIRA] in > > > > title. > > > > > > > > > " > > > > > > > > > > though we do not need additional efforts to make it happen, > > > > > > > > > > the only thing we need to get a consensus on is that, we need to > use > > > JIRA > > > > > to track work items and title PRs with JIRA ids > > > > > > > > > > > > > What ??? elaborate please?? > > > > > > > > > > > > > > Hi, all, a friendly reminder, the vote will be ended at 12:00 p.m. > on > > > > this > > > > > Friday > > > > > > > > > > > > > > > Best, > > > > > > > > > > Nan > > > > > > > > > > > > > > > > > > > > On Tue, Feb 27, 2018 at 1:44 PM, Suneel Marthi <smar...@apache.org > > > > > > wrote: > > > > > > > > > > > Suggest you see how other projects are doing it - Flink, Kafka or > > any > > > > > other > > > > > > project. > > > > > > > > > > > > Yes u r right. > > > > > > > > > > > > When u make a github PR with PR label in title like [Flink-3456] > > for > > > > eg: > > > > > - > > > > > > that way the corresponding JIRA - Flink-3456 here would be > > > > automatically > > > > > > updated. > > > > > > > > > > > > On Tue, Feb 27, 2018 at 10:28 PM, Nan Zhu < > zhunanmcg...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > Hi, Suneel, > > > > > > > > > > > > > > how can we enable it? when we titled JIRA id in pull request, > it > > > will > > > > > > > synchronized automatically? > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Nan > > > > > > > > > > > > > > On Tue, Feb 27, 2018 at 1:23 PM, Suneel Marthi < > > smar...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > > > 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 < > > > > > > steffenroc...@gmail.com > > > > > > > > > > > > > > > > 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 < > > > indhubhara...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > +1 to the proposal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu < > > > zhunanmcg...@gmail.com> > > > > > > > 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 < > > > > > > > > cjolivie...@gmail.com> > > > > > > > > > > > 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 < > > > > > > > > cjolivie...@gmail.com > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu < > > > > > > > > > > > > > marco.g.ab...@googlemail.com> 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" < > > > > > > > > > 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 > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >