You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mxnet.apache.org by CodingCat <co...@apache.org> on 2018/02/23 17:07:16 UTC

[VOTE] tracking code changes with JIRA by associating pull requests

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

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by CodingCat <co...@apache.org>.
Hi, Marco,

Thanks for the questions

> "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.

For this I would still prefer keep it as a case without a JIRA (though not
a tiny fix), the hotfix here actually refers to the process of "identify
which commit broke the build, revert the commit". After the hotfix, we
should "reopen the JIRA associated with the commit, and let the original
author resume the work on that"

> How would we handle permissions? Which actions are non-committers able to execute
and in which cases would a committer be required?

the general idea is that:

non-committers:

* create/modify/close their own JIRAs,

* link JIRAs, etc.

committers:

* create/modify/close all JIRAs,

* assign JIRA to someone (note, this action should be done when a PR is
available, otherwise, anyone can work on this JIRA)

* set target version of JIRA (i.e. committers should plan the dev work),
this action can be performed before/after PR is merged

> How would we treat GitHub issues in future? As a board for users to ask usage
questions?

Yes, that's also my understanding

> 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"

my concern is that potential bottleneck on more experienced people, we
would encourage the new devs follow the management strategy of the
community from their first day, and getting familiar with Apache's JIRA can
be part of it.

I think "please create a ticket" might be painful in the first few weeks as
people always needs to get used to something new.

I would suggest all committers collaborate together to ensure that the idea
(if it is good) can be accepted in the community-wide and realized as fast
as possible

Your thoughts?

Best,

Nan



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" <co...@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
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Sebastian Schelter <ss...@googlemail.com>.
+1

2018-02-27 23:59 GMT+01:00 Nan Zhu <zh...@gmail.com>:

> sure, will reflect it when add the content of the vote to the wiki
>
> On Tue, Feb 27, 2018 at 2:46 PM, Suneel Marthi <sm...@apache.org> wrote:
>
> > On Tue, Feb 27, 2018 at 11:44 PM, Marco de Abreu <
> > marco.g.abreu@googlemail.com> wrote:
> >
> > > 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.
> > >
> >
> > Agreed. I feel its unnecessary too - let's leave the [MODULE] out.
> >
> > >
> > > -Marco
> > >
> > > On Tue, Feb 27, 2018 at 11:34 PM, Yuan Tang <te...@gmail.com>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <sm...@apache.org>
> > > wrote:
> > > >
> > > > > On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zh...@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
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.
sure, will reflect it when add the content of the vote to the wiki

On Tue, Feb 27, 2018 at 2:46 PM, Suneel Marthi <sm...@apache.org> wrote:

> On Tue, Feb 27, 2018 at 11:44 PM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
> > 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.
> >
>
> Agreed. I feel its unnecessary too - let's leave the [MODULE] out.
>
> >
> > -Marco
> >
> > On Tue, Feb 27, 2018 at 11:34 PM, Yuan Tang <te...@gmail.com>
> > wrote:
> >
> > > +1
> > >
> > > On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <sm...@apache.org>
> > wrote:
> > >
> > > > On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zh...@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
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Suneel Marthi <sm...@apache.org>.
On Tue, Feb 27, 2018 at 11:44 PM, Marco de Abreu <
marco.g.abreu@googlemail.com> wrote:

> 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.
>

Agreed. I feel its unnecessary too - let's leave the [MODULE] out.

>
> -Marco
>
> On Tue, Feb 27, 2018 at 11:34 PM, Yuan Tang <te...@gmail.com>
> wrote:
>
> > +1
> >
> > On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <sm...@apache.org>
> wrote:
> >
> > > On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zh...@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 <sm...@apache.org>
> > > wrote:
> > > >
> > > > > On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zh...@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
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Marco de Abreu <ma...@googlemail.com>.
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 <te...@gmail.com> wrote:

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

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Yuan Tang <te...@gmail.com>.
+1

On Tue, Feb 27, 2018 at 5:31 PM Suneel Marthi <sm...@apache.org> wrote:

> On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zh...@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 <sm...@apache.org>
> wrote:
> >
> > > On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zh...@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 <sm...@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 <zh...@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
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Suneel Marthi <sm...@apache.org>.
On Tue, Feb 27, 2018 at 11:23 PM, Nan Zhu <zh...@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 <sm...@apache.org> wrote:
>
> > On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zh...@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 <sm...@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 <zh...@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
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.
> 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 <sm...@apache.org> wrote:

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

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Suneel Marthi <sm...@apache.org>.
On Tue, Feb 27, 2018 at 10:50 PM, Nan Zhu <zh...@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 <sm...@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 <zh...@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 <sm...@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 <in...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1 to the proposal
> > > > > >
> > > > > >
> > > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.
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.

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,
"

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

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 <sm...@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 <zh...@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 <sm...@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 <in...@gmail.com>
> > wrote:
> > > >
> > > > > +1 to the proposal
> > > > >
> > > > >
> > > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Suneel Marthi <sm...@apache.org>.
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 <zh...@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 <sm...@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 <in...@gmail.com>
> wrote:
> > >
> > > > +1 to the proposal
> > > >
> > > >
> > > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.
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 <sm...@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 <st...@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 <in...@gmail.com> wrote:
> >
> > > +1 to the proposal
> > >
> > >
> > > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Suneel Marthi <sm...@apache.org>.
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 <st...@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 <in...@gmail.com> wrote:
>
> > +1 to the proposal
> >
> >
> > On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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 <cj...@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
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Steffen Rochel <st...@gmail.com>.
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 <in...@gmail.com> wrote:

> +1 to the proposal
>
>
> On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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 <cj...@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 <cj...@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
> > > >>
> > > >
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Indhu <in...@gmail.com>.
+1 to the proposal


On Tue, Feb 27, 2018, 9:20 AM Nan Zhu <zh...@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 <cj...@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 <cj...@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" <co...@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
> > >>
> > >
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.
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 <cj...@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 <cj...@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" <co...@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
> >>
> >
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.
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 <cj...@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" <co...@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
>>
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.
+1


On Fri, Feb 23, 2018 at 9:56 AM Marco de Abreu <ma...@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" <co...@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
>

Re: [VOTE] tracking code changes with JIRA by associating pull requests

Posted by Marco de Abreu <ma...@googlemail.com>.
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" <co...@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