mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com>
Subject Re: [VOTE] tracking code changes with JIRA by associating pull requests
Date Tue, 27 Feb 2018 22:44:24 GMT
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 <terrytangyuan@gmail.com> wrote:

> +1
>
> On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <smarthi@apache.org> wrote:
>
> > On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zhunanmcgill@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 <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