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 17:18:22 GMT
Ideally, the JIRA work item should be created before coding starts -- long
before the PR.  So, I would suggest we don;t automatically create JIRAs
because then it sort of defeats the purpose of JIRA managing a backlog.

On Thu, 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