Re: users@mxnet

I don't want to argue here, as "Apache way" also says VOTE should not be a way to enforce our opinion, and consensus need to be reached through discussion Thanks! Tianqi On Fri, Jun 15, 2018 at 9:41 PM, Tianqi Chen wrote: > Then who should represent the users who are using the forums but not

Re: users@mxnet

Then who should represent the users who are using the forums but not the mail-list? I personally think it is a bit abuse use of the term "Apache way" to force our mind into the entire community... Maybe I am wrong.. Tianqi On Fri, Jun 15, 2018 at 9:39 PM, Sergio Fernández wrote: > Well, I do

Re: users@mxnet

Well, I do respect what you discussed in that meetup, if course. But for those who weren't there, maybe the decision taken what a bit bias. In Apache we like to say that "if it didn't happen on the mailing list s, it didn't happen" ;-) Look like there are different feelings about this. Should I

Re: users@mxnet

So unless there is a strong evidence that our community users prefers the mail-list, I would recommend we keep the current way Tianqi On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández wrote: > Are we targeting just Seattle as our community? I really hope we are > thinking a bit beyond that...

Re: users@mxnet

I do think we are targeting all the community, but we must also agree that the voice of users from the meetup is a representative sample of users' demand, and it is important that we respect that. Tianqi On Fri, Jun 15, 2018 at 9:25 PM, Sergio Fernández wrote: > Are we targeting just Seattle

Re: users@mxnet

Are we targeting just Seattle as our community? I really hope we are thinking a bit beyond that... On Fri, Jun 15, 2018, 21:22 Tianqi Chen wrote: > I remember last time during the mxnet meetup in Seattle, we did a survey, > and most users preferred the current discuss forum. So I would say we

Re: users@mxnet

I remember last time during the mxnet meetup in Seattle, we did a survey, and most users preferred the current discuss forum. So I would say we stick with that given the user community prefers that Tianqi On Fri, Jun 15, 2018 at 9:13 PM, Sergio Fernández wrote: > Then, if everybody agree,

Re: users@mxnet

Then, if everybody agree, let's request the mailing list creation to INFRA ;-) Marco, I wouldn't do that. Typically developers are also subscribed there, since they may be the most informed people for answering users' questions. But the topics discussed there may not be of the interest for pure

Re: users@mxnet

I think nobody was opposed to it in the past, right? I'd propose that all emails automatically get copied to dev@ to ensure high visibility initially. What do you think? Sebastian schrieb am Fr., 15. Juni 2018, 20:51: > I have already proposed this many times in the past and would strongly >

Re: users@mxnet

I have already proposed this many times in the past and would strongly encourage it. -s On 15.06.2018 21:56, Sergio Fernández wrote: Hi, is there any good reason why the podling doesn't have a users@ mailing list yet? Honestly speaking, I'm not a big fan of the other tools the podling is

users@mxnet

Hi, is there any good reason why the podling doesn't have a users@ mailing list yet? Honestly speaking, I'm not a big fan of the other tools the podling is using. Slack and Web forums a cool tools, and I used them a lot in other contexts. But when it comes to transparency and community, mailing

Re: Request for Sign up

Hi, Have you checked out this page? https://mxnet.incubator.apache.org/community/contribute.html The dev comm section has info on how to subscribe to the mail list. I think Steffen already added you to slack. On Fri, Jun 15, 2018, 16:33 Kalyanee Chendke wrote: > Hello, > > Bumping this up. I

Re: Request for Sign up

Hello, Bumping this up. I would like to request to sign up. -Kalyanee Kalyanee On Thu, Jun 7, 2018 at 11:27 AM, Kalyanee Chendke wrote: > Hey! > > I would like to request for sign up to the MXNet Apache Mailing list & > also to the MXNet Slack Channel. > > Kalyanee >

Re: Reverting pull request

Hey all, Although I am not a committer, and also have not contributed to MXNet as much as I would have wanted, wanted to chime in. Based on my experience doing SW dev for quite some time, I think that holding a high bar for the code that gets merged is a very positive thing - including making

Re: Reverting pull request

Hi, We can have a separate discussion on whether this was a friendly way to bring this up or not, but I don't see why we shouldn't roll back, share design on dev, fix the bug and add performance benchmarking results and call for reviews on a new PR. This seems to be a big change which was

Re: Reverting pull request

Hi Marco, You really want to bring it into Amazon internal planning meeting. I have been requesting to focus on fixing bugs for several weeks, instead of adding new features. But I didn't get a concrete time when it will happen. Best Mu On Fri, Jun 15, 2018 at 3:03 PM, Marco de Abreu <

Re: Reverting pull request

The way I see it: 1) you are just complaining and have never written code that fixes flaky tests 2) you are actively introducing bugs to the CI that causes it to fail in ways unrelated to any tests Eric On 2018/06/15 22:03:29, Marco de Abreu wrote: > CI doesn't fail for no reason but

Re: Reverting pull request

CI doesn't fail for no reason but because some people prefer to push new features than to get our codebase actually stable. We currently have 51 [1] flaky tests and I have only seen a few people (thanks Sheng, Alex and Pedro) work on the problem. So instead of complaining, take part and help

Re: Reverting pull request

send to *dev*-*un*subscr...@mxnet.incubator.apache.org On Fri, Jun 15, 2018 at 2:59 PM, Chris Olivier wrote: > does anyone know how to unsubscribe from this list? > > > On Fri, Jun 15, 2018 at 2:56 PM Haibin Lin > wrote: > > > Why revert the PR when we know there's a fix? > > If we keep

Re: Reverting pull request

Moving this to private, I don't want our contributors to get discouraged by our internal bickering. Mu, we have to start somewhere..your comment "find enough reviewers to provide useful feedbacks for major changes." is pretty condescending and I take objection to it. By now Eric, you and Tianqi

Re: Reverting pull request

does anyone know how to unsubscribe from this list? On Fri, Jun 15, 2018 at 2:56 PM Haibin Lin wrote: > Why revert the PR when we know there's a fix? > If we keep going backwards like this, no progress can be made. > > On Fri, Jun 15, 2018 at 2:37 PM, Mu Li wrote: > > > Agree that major

Re: Reverting pull request

We have the rule that a pull request must receive an approval from at least one committer and that they must have test coverage. Both rules have been broken multiple times. I view this situation independent of the actual bug but just from the fact that it has been self-merged without approval.

Re: Reverting pull request

Why revert the PR when we know there's a fix? If we keep going backwards like this, no progress can be made. On Fri, Jun 15, 2018 at 2:37 PM, Mu Li wrote: > Agree that major changes need more extensive reviews. But we cannot ignore > that both reviews and CI cannot catch all bugs. Reverting

Re: Reverting pull request

Hi Marco de Abreu, CI has been totally broken recently. It randomly fails for no good reason more often than it passes. For example the ccache/efs failure has been really annoying. Looks like there has been many changes to Jenkins and Docker lately. Do you think we should revert all of the

Re: Reverting pull request

Agree that major changes need more extensive reviews. But we cannot ignore that both reviews and CI cannot catch all bugs. Reverting each PR after finding a bug should be the last ways, before it, we should try to fix it first. As for the breaking change, I see it differently. It breaks a not

Re: Reverting pull request

Copying a comment I made on a flaky test introduced by this PR: https://github.com/apache/incubator-mxnet/issues/11171 " @piiswrong you introduced this test in this commit [WIP] Do Not Merge. Static memory allocation for cached_op (#10817

Re: Reverting pull request

He already sends in the fix. I agree with your point about not being self-merging, but a proper way would bring this issue up friendly and move forward with a better fix. We should not shoot every contributor for a bug they introduced due to new features as long as they take responsibility to fix

Re: Reverting pull request

If it causes issues, I'd like to invite everybody to direct their requests to Eric since he merged the PR prematurely. The committer who merges a PR is responsible and can be held liable for any negative impact being the result of their action [1]. [1]:

Re: MXNet issues labeling

Mentors, do you know if it is possible to get a bot account with these restricted permissions? I know that previous requests have been declined by Apache Infra. Shall we try it again or how shall we continue moving forward? -Marco On Fri, Jun 15, 2018 at 2:09 PM Qing Lan wrote: > Hi All, > I

Re: Reverting pull request

+1 The PR has been merged a while ago, so it has been tested by many people. Other people's work now depends on this PR. Reverting it at this point can cause a lot of problems for many other people. Best, Da On 6/15/18, 2:18 PM, "workc...@gmail.com on behalf of Tianqi Chen" wrote: +1

Re: Reverting pull request

We revert a PR because it should not have been merged in the first place. So far, I have been ignoring the fact that our committers are constantly breaking our own rules (which we expect contributors to follow). But since this caused an impact twice (1.2 breaking change about model import/export

Re: Reverting pull request

+1 We would be stuck at local minimums if we just keep reverting the PR that brings improvements in the long term Tianqi On Fri, Jun 15, 2018 at 2:15 PM, Mu Li wrote: > Why reverting instead of fixing the bugs? Static memory aims to reduce > memory allocation, it's a key feature to bridge

Re: Reverting pull request

Why reverting instead of fixing the bugs? Static memory aims to reduce memory allocation, it's a key feature to bridge the perf gap between gluon and symbol. On Fri, Jun 15, 2018 at 2:06 PM, Marco de Abreu < marco.g.ab...@googlemail.com.invalid> wrote: > Hello, > > I'm reverting

Re: MXNet issues labeling

Hi All, I would like to quote this: ``` Cathy: I am working on this label bot to automate/simplify this labeling issue process and send weekly report to maintainers. Design proposal is on cwiki: https://cwiki.apache.org/confluence/display/MXNET/Deep+Learning+Based+GitHub+Label+Bot Please feel

Reverting pull request

Hello, I'm reverting https://github.com/apache/incubator-mxnet/pull/10817 as of https://github.com/apache/incubator-mxnet/pull/11311 due to regressions described in https://github.com/apache/incubator-mxnet/issues/11171 and https://github.com/apache/incubator-mxnet/pull/10817. The pull request

Re: Update on 1.2.1 release

Hello, we would need this PR to be merged as well: https://github.com/apache/incubator-mxnet/pull/11309 With the next deployment of new Windows slaves (which should happen asap), the 1.2 branch and all past branches are going to break since the test execution is not versioned. Please merge this

Re: About Becoming a Committer

First of all, Apache allows each community to define its standard of comittership -- which I think is super valuable as different projects have different backgrounds and challenges. Having such flexibility instead of enforcing a global standard is one of the reasons why many Apache projects

Re: Clojure Package

Kovas Boguta https://twitter.com/kovasb, from the Clojure/AI community, graciously took some time to review the PR for the clojure package. He had some insightful feedback and high level questions that I thought might be of interest to the larger dev mailing list.

Re: About Becoming a Committer

Totally agree, thanks for elaborating! Hen schrieb am Fr., 15. Juni 2018, 00:44: > That wasn't what I was trying to say (I'll try again - tis late and I'm > sure I'm speaking poorly :) ). > > It says: > > "When it comes to code contributions, quality is more important than > quantity. While all

Re: About Becoming a Committer

That wasn't what I was trying to say (I'll try again - tis late and I'm sure I'm speaking poorly :) ). It says: "When it comes to code contributions, quality is more important than quantity. While all contributions are welcome and highly appreciated, certain guidelines will be applied when it

Re: About Becoming a Committer

Hen, As you stated, it's of significance of how much a PR has to be changed as a result of a review. I think this is what this project defines as quality. If people submit a bunch of PRs and we reviewers spend a lot of time on every single one of them to give the contributors advice about how to

Re: About Becoming a Committer

On the 'Becoming+a+Committer' guidelines, I dislike this phrase: "When it comes to code contributions, quality is more important than quantity" There is only one 'quality' measurement, and that is "was the code merged". If someone makes 10 different contributions and they were all horrible and

Re: About Becoming a Committer

On Tue, Jun 12, 2018 at 10:54 PM, Pedro Larroy wrote: > * I personally don't like the idea that comittership status is decided in a > closed mail list. This is not the transparency level that I would expect in > an open source project. I'm happy to receive feedback from others that > might be

Re: GitHub Label Bot Design

Thanks Cathy. As a high level concept, scripts the project depends on should be committed to the project (I say this more as a note for everyone rather than calling you out specifically :) ). Hen On Thu, Jun 14, 2018 at 9:31 PM, Yuelin Zhang wrote: > Hi Hen, > > I am not using probot. Now my