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 22:23:31 GMT
> 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 <smarthi@apache.org> wrote:

> On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zhunanmcgill@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 <smarthi@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 <zhunanmcgill@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 <smarthi@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 <
> > > steffenrochel@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 <indhubharathi@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > +1 to the proposal
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zhunanmcgill@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 <
> > > > > 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