mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xingjian SHI <xsh...@connect.ust.hk>
Subject Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests
Date Thu, 08 Mar 2018 19:19:40 GMT
We can also consider to give a special label for all the issues that are "working items". There
are lots of efforts spent on assigning the correct label to Github issues. We can then easily
select the issues we are interested in, e.g, https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+request%22


Xingjian


________________________________
From: Naveen Swamy <mnnaveen@gmail.com>
Sent: Friday, March 9, 2018 3:08 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

I don't think we should transfer all Github issues to Jira that will make
Jira issues unmanageable and pretty useless, also not all issues are being
worked on or will be worked on. I like the idea of using Jira as a backlog,
so contributors/committers create Jira tasks/projects based on what they
are working on.

On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <anirudh2290@gmail.com> wrote:

> There should be an easy way to translate all the existing github issues
> into work items in JIRA(Considering the work on labelling that is done for
> github issues).
> Does the JIRA bot handle this ?
>
> On Thu, Mar 8, 2018 at 10:40 AM, Chris Olivier <cjolivier01@gmail.com>
> wrote:
>
> > Anyone can create a backlog item/JIRA ticket.
> >
> > Obvious cases might include:
> >
> > * Someone thinks of a task and (optionally) wants to develop it
> themselves,
> > so they create a backlog item and assign it to themself, putting it into
> > "in progress" mode.
> > * Someone dreams up a large feature and wants to create an epic with 30
> > subtasks, so they create the epic and its subtasks (grooming)
> > * Someone wants to just pick up a random pre-existing backlog item to
> work
> > on
> >
> > I do think that backlog items should be restricted to actual work items
> and
> > not general issue reporting, but I'm certainly open to how other Apache
> > projects like Spark do that.  So far it seems like github issues do a
> > pretty good job of that.
> >
> >
> > On Thu, Mar 8, 2018 at 10:26 AM, Sheng Zha <szha.pvg@gmail.com> wrote:
> >
> > > Good points on keeping a public backlog. Should we expect new
> > contributors
> > > to create such backlog items? Or who should own the responsibility of
> > > creating backlog items?
> > >
> > > - Sent by my thumb
> > >
> > > > On Mar 8, 2018, at 10:14 AM, Nan Zhu <zhunanmcgill@gmail.com> wrote:
> > > >
> > > > just giving an example about Chris's opinion (how JIRA would help for
> > > more
> > > > new users)
> > > >
> > > > I can see Spark 2.4 is highly possible to include the nested column
> > > pruning
> > > > in parquet file from its JIRA (
> > > > https://issues.apache.org/jira/browse/SPARK-4502)
[SPARK-4502] Spark SQL reads unneccesary nested fields ...<https://issues.apache.org/jira/browse/SPARK-4502>
issues.apache.org
When reading a field of a nested column from Parquet, SparkSQL reads and assemble all the
fields of that nested column. This is unnecessary, as Parquet supports fine ...



> > > >
> > > > it's hard for me to have any source to get the similar expectation
> for
> > > MXNET
> > > >
> > > > Best,
> > > >
> > > > Nan
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Mar 8, 2018 at 10:03 AM, Chris Olivier <
> cjolivier01@gmail.com>
> > > > wrote:
> > > >
> > > >> Almost all Apache projects use JIRA.  It's been proven to work in
> > > >> open-source.
> > > >> Having backlog/development process public hopefully will help
> > adoption.
> > > >> Right now, what new users?  Adoption is very slow, so I think it's
> > hard
> > > to
> > > >> argue that the current way of doing things is effective.
> > > >>
> > > >>> On Thu, Mar 8, 2018 at 9:44 AM, Sheng Zha <szha.pvg@gmail.com>
> > wrote:
> > > >>>
> > > >>> Cool. Feel free to propose a change to the PR template.
> > > >>>
> > > >>> How would JIRA be less daunting to new users?
> > > >>>
> > > >>> -sz
> > > >>>
> > > >>>> On Mar 8, 2018, at 9:25 AM, Chris Olivier <cjolivier01@gmail.com>
> > > >> wrote:
> > > >>>>
> > > >>>> My $0.02 about the PR template.
> > > >>>>
> > > >>>> I think it's a good idea.  I think (just my opinion) is that
the
> > > >> adoption
> > > >>>> is low because it started out too big and daunting.  It may
get
> more
> > > >>>> adoption if we started a little smaller -- with maybe two
> > checkboxes"
> > > >> and
> > > >>>> also didn't have a line at the top stating "Description",
because
> > that
> > > >>> feel
> > > >>>> skind of awkward and github inserts extended label info above
it
> > > >>> sometimes.
> > > >>>>
> > > >>>> Just an idea.
> > > >>>>
> > > >>>>> On Thu, Mar 8, 2018 at 9:13 AM, Sheng Zha <szha.pvg@gmail.com>
> > > wrote:
> > > >>>>>
> > > >>>>> The PR template is designed for that and its poor adoption
is
> > causing
> > > >>> the
> > > >>>>> same issue of missing information in PRs. My concern of
using
> JIRA
> > is
> > > >>> that
> > > >>>>> more overhead would deter contribution and worsen the
quality of
> > > >>>>> description.
> > > >>>>>
> > > >>>>> -sz
> > > >>>>>
> > > >>>>>> On Mar 8, 2018, at 8:49 AM, Nan Zhu <zhunanmcgill@gmail.com>
> > wrote:
> > > >>>>>>
> > > >>>>>> +1 on both suggestions
> > > >>>>>>
> > > >>>>>> a bit concern is on the quality of JIRA which is created
> > > >> automatically
> > > >>>>>>
> > > >>>>>> I can see a lot of PRs are not described comprehensively,
if we
> > just
> > > >>> post
> > > >>>>>> what in description to JIRA, it's error-propagating
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> but the quality of JIRA is a big topic worth more
discussions
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Thu, Mar 8, 2018 at 3:06 AM, Marco de Abreu <
> > > >>>>> marco.g.abreu@googlemail.com
> > > >>>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Would it be possible to automatically create JIRA
tickets when
> a
> > > >>> GitHub
> > > >>>>>>> issue is being created? We could then mirror all
comments the
> > same
> > > >> way
> > > >>>>> it's
> > > >>>>>>> happening in https://issues.apache.org/
issues.apache.org<https://issues.apache.org/>
issues.apache.org
Apache currently hosts two different issue tracking systems, Bugzilla and Jira. To find out
how to report an issue for a particular project, please visit the project ...



> > jira/projects/MXNET/issues/
> > > >>>>> MXNET-42
> > > >>>>>>> but make sure that the bot works in both ways.
A comment on
> > GitHub
> > > >>>>> would be
> > > >>>>>>> copied to JIRA and a JIRA comment to GitHub. I
think this would
> > be
> > > >>> good
> > > >>>>> as
> > > >>>>>>> a first step to start integration.
> > > >>>>>>>
> > > >>>>>>> -Marco
> > > >>>>>>>
> > > >>>>>>> On Wed, Mar 7, 2018 at 8:08 PM, Marco de Abreu
<
> > > >>>>>>> marco.g.abreu@googlemail.com
> > > >>>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> I also see this as a big advantage in terms
of transparency. I
> > > >>>>> personally
> > > >>>>>>>> will try to move away from any company internal
issue trackers
> > > >>> (except
> > > >>>>>>> for
> > > >>>>>>>> confidential cases) and instead work on Jira
that is being
> > managed
> > > >> by
> > > >>>>> the
> > > >>>>>>>> community. This allows everybody to see what
is being worked
> on
> > > and
> > > >>>>> gives
> > > >>>>>>>> them the possibility to chime with ideas or
suggestions.
> > > >>>>>>>>
> > > >>>>>>>> In my opinion, this obsoletes TT and SIM to
a big extent. It's
> > up
> > > >> to
> > > >>>>> you
> > > >>>>>>>> if you maintain multiple issue trackers or
stick to one. If
> > > anybody
> > > >>>>> has a
> > > >>>>>>>> (non-confidential) issue that's related to
my work on CI, I
> ask
> > > >> them
> > > >>> to
> > > >>>>>>>> create a GitHub issue instead of a company
internal ticket - I
> > > >> invite
> > > >>>>>>>> everybody to do the same.
> > > >>>>>>>>
> > > >>>>>>>> MXNet is an open source project and moving
away from company
> > > >> internal
> > > >>>>>>>> trackers towards community driven ones is
the next logical
> step
> > in
> > > >> my
> > > >>>>>>>> opinion. At the moment, everybody is working
on their own and
> > it's
> > > >>> hard
> > > >>>>>>> to
> > > >>>>>>>> see for external people (or even developer
who are not part of
> > the
> > > >>> same
> > > >>>>>>>> team) what we're actually working on.
> > > >>>>>>>>
> > > >>>>>>>> -Marco
> > > >>>>>>>>
> > > >>>>>>>>> On Wed, Mar 7, 2018 at 7:48 PM, Naveen
Swamy <
> > mnnaveen@gmail.com
> > > >
> > > >>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> I am +1 for using JIRA. Managing bigger
projects within MXNet
> > on
> > > >>> JIRA
> > > >>>>>>>>> brings openness to the project. MXNet
Users and the
> > contributors
> > > >>> also
> > > >>>>>>> get
> > > >>>>>>>>> a
> > > >>>>>>>>> sense of where the project is heading.
> > > >>>>>>>>> Bigger Tasks can be divided into sub-tasks
which contributors
> > can
> > > >>> pick
> > > >>>>>>> up
> > > >>>>>>>>> small tasks based on their expertise on
and contribute
> > > >>> independently.
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Mar 7, 2018 at 10:40 AM, Chris
Olivier <
> > > >>> cjolivier01@gmail.com
> > > >>>>>>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> The vote was discussed on private@
before the vote on dev@,
> > and
> > > >>> the
> > > >>>>>>>>> vote
> > > >>>>>>>>>> went on for a very long time.  There
was ZERO resistance.
>  No
> > > >> one
> > > >>>>>>>>> "snuck"
> > > >>>>>>>>>> it in or "slipped it by".
> > > >>>>>>>>>>
> > > >>>>>>>>>> This, hopefully, phases out both SIM
and tt, which are both
> > are
> > > >>> being
> > > >>>>>>>>> used
> > > >>>>>>>>>> in ways that aren't what they're even
designed for, IMO.
> > > Trouble
> > > >>>>>>>>> tickets
> > > >>>>>>>>>> are being used as a backlog for my
team, which is insane.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I've actually sent out a couple of
mails on dev about
> contact
> > me
> > > >> if
> > > >>>>>>> you
> > > >>>>>>>>>> don't have access to JIRA.  If you
would like to participate
> > in
> > > >> the
> > > >>>>>>>>>> direction of the project, please keep
up with the dev email
> > > list.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I gave you contributor permissions
on JIRA, btw.
> > > >>>>>>>>>> .
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, Mar 7, 2018 at 10:17 AM, Aaron
Markham <
> > > >>>>>>>>> aaron.s.markham@gmail.com>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> I'm not quite sure if I have enough
background on reasons
> for
> > > or
> > > >>>>>>>>> against
> > > >>>>>>>>>>> this to vote in the next round,
but my two cents: I didn't
> > see
> > > >>> much
> > > >>>>>>>>>> debate
> > > >>>>>>>>>>> on why we need yet another tool
for issues that we have to
> > > >>> manually
> > > >>>>>>>>>>> maintain...the vote kind of slid
in there without many
> > > >>> stakeholders
> > > >>>>>>>>>>> realizing what they were being
signed up for. I was
> thinking,
> > > >>> sure,
> > > >>>>>>> if
> > > >>>>>>>>>> YOU
> > > >>>>>>>>>>> want to make jira tickets, go
right ahead. I have two
> > internal
> > > >>>>>>>>> ticketing
> > > >>>>>>>>>>> systems to deal with already that
assign tasks on MXNet,
> plus
> > > >>>>>>> GitHub.
> > > >>>>>>>>>> Jira
> > > >>>>>>>>>>> would be four. Happy to make it
work, but I'll need fifth
> > tool
> > > >> to
> > > >>>>>>>>>> aggregate
> > > >>>>>>>>>>> communications and metrics between
the other four tools!
> I'm
> > > >> only
> > > >>>>>>>>> sort of
> > > >>>>>>>>>>> joking.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I saw Chris's response, and ok
the public visibility part
> > makes
> > > >>>>>>> sense,
> > > >>>>>>>>>> but
> > > >>>>>>>>>>> does this phase out any other
overhead? Does it integrate?
> > Jira
> > > >>> has
> > > >>>>>>>>>>> integration options so maybe we
can eliminate some
> > overhead...
> > > >>> Like
> > > >>>>>>>>>>> something that hooks into the
GitHub api and generates jira
> > > >>> tickets
> > > >>>>>>> on
> > > >>>>>>>>>> the
> > > >>>>>>>>>>> fly... I want to believe there's
a plan that makes this all
> > > >>> easier.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> What value I don't see is how
we lower barriers to
> > contribution
> > > >>> and
> > > >>>>>>>>> make
> > > >>>>>>>>>> it
> > > >>>>>>>>>>> more fluid for new users that
could become contributors.
> > What's
> > > >>> the
> > > >>>>>>>>> story
> > > >>>>>>>>>>> and value proposition?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Also, I don't see any docs on
the website or on github on
> how
> > > to
> > > >>>>>>> sign
> > > >>>>>>>>> up
> > > >>>>>>>>>>> for jira, or how to contribute
according to this new
> > > requirement
> > > >>>>>>>>> anywhere
> > > >>>>>>>>>>> on the site. Myself and new contributors
wouldn't know what
> > the
> > > >>>>>>>>> expected
> > > >>>>>>>>>>> flow looks like because it's not
really accessible. I now
> see
> > > >> the
> > > >>>>>>>>>>> confluence wiki, but that's pretty
much hidden from anyone
> > > >>> browsing
> > > >>>>>>>>> the
> > > >>>>>>>>>>> site or github and looking to
contribute. Why is this info
> on
> > > >>>>>>>>> confluence
> > > >>>>>>>>>> at
> > > >>>>>>>>>>> all? Why not in the docs on github
that are rendered to the
> > > >>> website?
> > > >>>>>>>>> Or
> > > >>>>>>>>>>> conversely, why is some of the
info on github and on the
> > > >> website,
> > > >>> if
> > > >>>>>>>>> it
> > > >>>>>>>>>> is
> > > >>>>>>>>>>> being maintained and current only
on confluence?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> These are two separate issues
really, but I think if you
> want
> > > >>>>>>> buy-in,
> > > >>>>>>>>>> this
> > > >>>>>>>>>>> needs to be more transparent and
obvious, and provide clear
> > > >>> reasons
> > > >>>>>>>>> and
> > > >>>>>>>>>>> benefits to why you're asking
for more overhead.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Aaron
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On Mar 6, 2018 21:14, "Eric
Xie" <jxie@apache.org> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> JIRA is ancient and arcane.
This adds unnecessary
> overhead.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 2018/03/03 06:11:12,
CodingCat <codingcat@apache.org>
> > > >> wrote:
> > > >>>>>>>>>>>>> This vote passes with
6 +1 votes (6 bindings) and no 0 or
> > -1
> > > >>>>>>>>> votes.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Binding +1:
> > > >>>>>>>>>>>>> Chris Olivier
> > > >>>>>>>>>>>>> Indhu Bharathi
> > > >>>>>>>>>>>>> Suneel Marthi
> > > >>>>>>>>>>>>> Yuan Tang
> > > >>>>>>>>>>>>> Marco de Abreu
> > > >>>>>>>>>>>>> Sebastian Schelter
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Vote thread:
> > > >>>>>>>>>>>>> https://lists.apache.org/list.
> > html?dev@mxnet.apache.org:lte=
> > > >>>>>>>>>>>> 1M:tracking%20code%20changes%20with%20JIRA%20by%
> > 20associatin
> > > >>>>>>>>>>>> g%20pull%20requests
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I will continue with pushing
the content to wiki and take
> > it
> > > >>>>>>> into
> > > >>>>>>>>>>>> practice
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
>

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