mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nan Zhu <zhunanmcg...@gmail.com>
Subject Re: [VOTE] tracking code changes with JIRA by associating pull requests
Date Tue, 27 Feb 2018 17:20:13 GMT
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 <cjolivier01@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 <cjolivier01@gmail.com>
> wrote:
>
> > +1
> >
> >
> > On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <
> > marco.g.abreu@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" <codingcat@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
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message