mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tianqi Chen <tqc...@cs.washington.edu>
Subject Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests
Date Thu, 08 Mar 2018 19:10:48 GMT
To summarize:

- JIRA might be more maintainer friendly(have more features for tracking
progress etc.)
- Github issues are more community friendly (it has been the way most
people contribute, and have lower bar of entry).

Tianqi

On Thu, Mar 8, 2018 at 11:05 AM, Xingjian SHI <xshiab@connect.ust.hk> wrote:

> There is no issue page in Spark (https://github.com/apache/spark) and
> they rely solely on JIRA to track the working items. This is different from
> what we are doing now. MXNet associate PRs to working items by linking them
> to the Github issues, e.g, https://github.com/apache/
> incubator-mxnet/pull/10029 links to https://github.com/apache/
> incubator-mxnet/issues/9950. If we rely on JIRA in the future, we need to
> emphasize the difference between Github issues and JIRA items or disable
> Github/issues and forces users to use JIRA.
>
> Personally, I think these two have similar functionalities and why don't
> we directly use Github issues? It's much easier for users as they do not
> need to create another account. Their contributions to MXNet (including
> creating issues) would also be directly displayed  in the Github homepage,
> which encourages them to do more for the community.
>
> Best,
> Xingjian
>
>
> ________________________________
> From: Nan Zhu <zhunanmcgill@gmail.com>
> Sent: Friday, March 9, 2018 2:14 AM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating
> pull requests
>
> 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/
> 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