mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nan Zhu <zhunanmcg...@gmail.com>
Subject Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests
Date Thu, 08 Mar 2018 18:14:38 GMT
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)

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