Re: open issues

[Henri Yandell]

I'd suggest writing up a triage process on the wiki.

Using labels makes a lot of sense. One label that I've found useful with
Issues in the past is "Patch Needed" (ie: contributors, please work on
these). Another would be "easyfix"; ie) new contributors, this is a good
place to start.

One of the 'problems' imo with GitHub's approach is that there's no real
place for 'backlog' or 'wishlist'. Requests for new things that you're
unlikely to work on soon get in the way of bugs. :(

Hen


On Thu, Aug 31, 2017 at 6:33 AM, Dom Divakaruni <
dominic.divakar...@gmail.com> wrote:

> Agree! The first step need to be to comb thru these and assign a tag. A
> hurdle with this is that, non committers, like myself don't have the
> ability to assign tags.
>
> Does anyone have a solution to get around that? Temporary roles, or task
> based credentials perhaps?
>
> As we solve that, we can propose a definition for tags - "outdated",
> "bug-needs investigation" and "FAQ" make sense as tags - and specific
> instructions for the cleanup crew.
>
> We can add a comment to each one of the "outdated" ones to say "is this
> still an issue? If there is no response, the issue will be closed after 2
> weeks"... or something like that
>
> After the tags comes the hard work :)
> That said, over 900 of these issues are older than Jan 1, and may by and
> large, be outdated.
>
>
> Regards,
> Dom
>
>
> > On Aug 31, 2017, at 2:10 AM, Chiyuan Zhang  wrote:
> >
> > I could also help with this from time to time. I think maybe at least
> half
> > of the issues are outdated, in the sense that the original reporter was
> no
> > longer working on it or able to provide enough details to reproduce it.
> > While some still correspond to important feature request or potential
> > serious bugs, many of them could probably be safely closed. I am not
> > advocating we should always close issues that are too old, clearly the
> best
> > way is really to resolve it if we have enough man power.
> >
> > I would suggest creating some tags for this, things could be 'out-dated',
> > 'FAQ', etc. And periodically sweep through the issues, if you see an
> issues
> > that should be closed due to inactivity, you label it as 'out-dated' and
> > leave a message saying that it will be closed after XXX days if remains
> > inactive. Or if it corresponds to some frequently asked questions, mark
> it
> > as 'FAQ'. And another sweep that also happens periodically could try to
> > close the issues marked for 'out-dated' for a while and assemble entries
> > into documentation for the 'FAQ' issues.
> >
> > - chiyuan
> >
> > On Thu, Aug 31, 2017 at 4:32 AM, Dominic Divakaruni <
> > dominic.divakar...@gmail.com> wrote:
> >
> >> fellow mxnet'ers, we have >1900 open issues on git. The most out of any
> >> deep learning framework. I am eager to carve out some time to work on
> >> reducing this backlog (to the extent of my technical ability). I'd like
> to
> >> make this a team effort to make a meaningful impact. Any ideas? Would
> you
> >> be open to an issue-clean-up-athon?
> >>
>

Re: Dependency directories?

[Henri Yandell]

I'm not sure for C/C++.

For the languages that have artifact repositories (Java, Python, Perl etc),
the norm is to use those systems.

It does feel weird to have an Apache source project with a large lump of
its code appearing to be the same product but not part of the project.

The approaches that naively jump out to me are:

1) As it currently is, linking MXNet to the other git repositories.
2) User installs them themselves and MXNet uses configure/make to build.
3) Copy the source over into the MXNet project.
4) Create new repositories at Apache for each of them (and then possibly
still just link them in).

Jim (or anyone else) - any advice you could offer on how C/C++ dependencies
are handled at Apache projects?


Hen

On Tue, Aug 29, 2017 at 10:55 PM, Chris Olivier 
wrote:

> I've been curious about the same thing. How do other Apache projects handle
> this sort of thing?
>
> What's are the pros and cons?
>
>
> On Tue, Aug 29, 2017 at 9:57 PM Henri Yandell  wrote:
>
> > What's the plan for the source that isn't included in the mxnet repo?
> >
> >  cub/
> >  dlpack/
> >  dmlc-core/
> >  mshadow/
> >  nnvm/
> >  ps-lite/
> >
> > Is the plan to keep those as separate DMLC packages, or to consider them
> > MXNet specific?
> >
> > Thanks,
> >
> > Hen
> >
>

Re: ICLAs vs Contributors

[Henri Yandell]

Hi tornadomeet :)

If you could sign this (ink, not typed) and email it to secret...@apache.org
that would be brilliant.

Thanks,

Hen


On Thu, Aug 31, 2017 at 9:19 AM, tornadomeet <1530735...@qq.com> wrote:

> hello, i'm tornadomeet, how to sign CLAs?
>
>
> thanks
>
>
> -- 原始邮件 --
> 发件人: "Henri Yandell";;
> 发送时间: 2017年8月30日(星期三) 中午1:06
> 收件人: "dev"; "John D. Ament"<
> johndam...@apache.org>; "Justin Mclean";
>
> 主题: ICLAs vs Contributors
>
>
>
> (cc to John and Justin as they'd asked about this)
>
> Looking at the current MXNet GitHub contributors list (411 contributors):
>
> We have 36 signed CLAs at this point.
>
> Of the top 36 contributors, the following 15 top contributors aren't
> covered by a CLA:
>
> 8:sneakerkg
> 9:kevinthesun  (post Incubation)
> 17:hjk41
> 18:mavenlin
> 19:tornadomeet
> 20:winstywang
> 21:jermainewang
> 22:qiaohaijun
> 23:vchuravy
> 25:Roshrini  (post Incubation)
> 26:howard0su
> 28:sbodenstein
> 31:ptrendx  (post Incubation)
> 35:zackchase   (post Incubation)
> 36:yanqingmen
>
> Note that some of these are post entering the Incubator.
>
> Some of the 411 contributors we should ask for CLA/SGs from. Those above
> are most likely the first to get agreements signed from, and we need to
> determine how far down the list to go.
>
> The git logs are trickier to use as they don't use the github login; so
> doing an analysis of the diffs themselves is trickier.
>
> Hen
>

[BUILD FAILED] Branch master build 293

[Apache Jenkins Server]

Build for MXNet branch master has broken. Please view the build at 
https://builds.apache.org/job/incubator-mxnet/job/master/293/