mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests
Date Thu, 08 Mar 2018 19:17:59 GMT
Oh my God, no...

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