> 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 > 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) On Tue, Feb 27, 2018 at 2:13 PM, Suneel Marthi <[email protected]> wrote: > On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > > > 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 < > > > [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 > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
