Re: [Annoucement] New Committer -- Iblis Lin

[Chiyuan Zhang]

Welcome Iblis! Thank you very much for your hard work and continuous
efforts on the Julia branch lately!

Best,
Chiyuan

On Sat, Jan 5, 2019 at 12:13 PM Carin Meier  wrote:

> Please join me in welcoming Iblis Lin as a new committer.
>
> He has been a long time contributor to the Julia package, is responsible
> for bringing into the main MXNet repo, and is the current maintainer.
>
> https://github.com/apache/incubator-mxnet/commits?author=iblis17
>
> - Carin Meier
>

Re: Julia Package Release Process

[Chiyuan Zhang]

I just checked that I have ability to disable the issue tracker on
dmlc/MXNet.jl. Iblis: let me know if you would like me to disable the issue
(after you transferred active ones to mxnet main repo). Disabling issues
makes the whole 'issues' tab disappear. I think we can also adopt clojure
repo's approach, instead of closing the issues completely, put a note there
to point to the main repo.

Best,
Chiyuan

On Mon, Jan 7, 2019 at 9:13 AM Iblis Lin  wrote:

> Yes, I have them on main repo.
> But for MXNet.jl, I'm repo collaborator.
> Anyway, I'm browsing the issues and migrating some of them.
>
> On 1/8/19 12:46 AM, Chris Olivier wrote:
> > Do you not have write permissions on mxnet repo?
> >
> > On Mon, Jan 7, 2019 at 6:13 AM iblis  wrote:
> >
> >> just found that I don't have the permission to transfer issues of
> >> dmlc/MXNet.jl.
> >> Could anyone help me on this?
> >>
> >> On 1/7/19 12:16 PM, iblis wrote:
> >>> okay.
> >>> Before disabling the issue tracker, I'm going to transfer the issue
> >>> from MXNet.jl to main repo.
> >>> (via
> >>
> https://help.github.com/articles/transferring-an-issue-to-another-repository/
> >> )
> >>>
> >>> On 1/7/19 12:17 AM, Chris Olivier wrote:
>  +1 for disabling issue tracker and putting a note on original repo (if
> >> it
>  isn’t already there) that work/issue tracking has moved to mxnet
> (using
>  julia label in github or Jira). m
> 
> 
>  On Sun, Jan 6, 2019 at 1:19 AM iblis  wrote:
> 
> > Before PR #10149 got merged (Oct 5, 2018) into main repo,
> > julia code is developed and maintained in the separate repo --
> > dmlc/MXNet.jl.
> >
> > After that PR, there are no further development happened in
> >> dmlc/MXNet.jl.
> > We work with the main repo now.
> > But the original MXNet.jl repo is still there, it just isn't deleted
> or
> > archived yet.
> > I receive some issue ticks from this repo occasionally,
> > maybe we should just disable the issue tracker of it.
> >
> >> Does it work with other frameworks other than mxnet?
> > hmm, I'm not sure what you mean.
> >
> > On 1/6/19 1:18 PM, Chris Olivier wrote:
> >> Curious:  Why is the julia code maintained in a separate repo? I was
> > under
> >> the impression that it was donated/permanently merged into the mxnet
> > source
> >> tree.  Does it work with other frameworks other than mxnet?
> >>
> >> On Sat, Jan 5, 2019 at 8:32 PM Iblis Lin 
> >> wrote:
> >>
> >>> If there is trademark issue, how about this option:
> >>>   3) transferring the MXNet.jl repo ownership from DMLC to
> Apache.
> >>>
> >>> On 1/6/19 6:45 AM, Justin Mclean wrote:
>  Hi,
> 
> >  1) Reuse the old repo: https://github.com/dmlc/MXNet.jl
> > It's under DMLC. I have the committer bit of this
> repo.
> 
>  I'm not 100% sure that would be allowed from a branding/trademark
> >>> perspective, any distribution owned by a 3rd party can't be called
> > "Apache
> >>> MXNet".
> 
> >  2) A new repo under ASF's organization?
> 
>  That seems preferable I think.
> 
>  Thanks,
>  Justin
> 
> >>>
> >>> --
> >>> Iblis Lin
> >>> 林峻頤
> >>>
> >>
> >
> > --
> > Iblis Lin
> > 林峻頤
> >
> 
> >>>
> >>
> >> --
> >> Iblis Lin
> >> 林峻頤
> >>
> >
>
> --
> Iblis Lin
> 林峻頤
>

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

Sorry, here is the image: https://imgur.com/V5wd2XB

And here is the github document on the 3 different merge options for the
web UI button: https://help.github.com/articles/about-pull-request-merges/

On Sat, Sep 29, 2018 at 6:48 PM Marco de Abreu
 wrote:

> Could you upload the picture somewhere please? HTML is being stripped out
> on email lists.
>
> Chiyuan Zhang  schrieb am So., 30. Sep. 2018, 03:44:
>
> > There is an option in the repo settings menu to disable or enable
> > merge-commit for PR, see a screenshot below (from a different github
> > project):
> >
> > [image: image.png]
> >
> > My guess is that this is disabled for the reason to avoid creating
> > non-linear history for standard PRs (as oppose to technical problem). But
> > this is only my guess, it would be great if someone could confirm.
> >
> > Best,
> > Chiyuan
> >
> > On Sat, Sep 29, 2018 at 3:50 AM Carin Meier 
> wrote:
> >
> >> I believe so, but if someone wants to confirm it would be great.
> >> Unfortunately, I just came down with a cold/flu so I will be out of
> >> communication for a bit
> >>
> >> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
> >>  wrote:
> >>
> >> > Are we sure that this is due to lacking permissions and not because of
> >> some
> >> > technical limitation? If we are certain, we can ask out mentors to
> >> create a
> >> > ticket with Apache Infra to make that switch.
> >> >
> >> > -Marco
> >> >
> >> > Carin Meier  schrieb am Sa., 29. Sep. 2018,
> >> 01:17:
> >> >
> >> > > I made a test regular merge commit into a copy of master. It seemed
> >> to go
> >> > > fine. Here is a listing of what it will look like for everyone.
> >> > >
> >> > >
> >> >
> >>
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> >> > >
> >> > > Although, I would be happy to push the merge button. I think the
> most
> >> > > important thing is to get the PR merged, so whatever way is the best
> >> to
> >> > > make that happen, let's do it.
> >> > >
> >> > > So - Does the regular merge seem like a good option?
> >> > > If so, what is the best way to make that happen?
> >> > >
> >> > >
> >> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> >> wrote:
> >> > >
> >> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> >> > > interface
> >> > > > was disabled for a reason. But as Pedro said, maybe it is good to
> >> > > > temporarily enable it for this PR and merge using that.
> >> > > >
> >> > > >
> >> > > >- It should be technically easier than rebasing due to the
> >> > > >git-subtree-import issue we are currently having
> >> > > >- It also avoid stacking a huge commit history on *top* of
> >> current
> >> > > >history
> >> > > >- The downside is probably the history of the project is not
> >> linear
> >> > > >anymore, but I think this is actually what we would like to
> have
> >> for
> >> > > > this
> >> > > >particular case, because the contents of the main repo and the
> >> julia
> >> > > > branch
> >> > > >actually does not overlap. So it makes sense to have two tails
> >> with
> >> > > > their
> >> > > >own history.
> >> > > >
> >> > > > Carin: I guess if someone with admin permission on the github
> could
> >> > > > temporarily enable the merge-commit option, then pushing the
> button
> >> on
> >> > > the
> >> > > > web might simply work.
> >> > > >
> >> > > > Best,
> >> > > > Chiyuan
> >> > > >
> >> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  >
> >> > > wrote:
> >> > > >
> >> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
> >> > > > originally
> >> > > > > ruled it out since it wasn't an option in the github web
> >> interface,
> >> > but
> >> > > > > since this lo

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

There is an option in the repo settings menu to disable or enable
merge-commit for PR, see a screenshot below (from a different github
project):

[image: image.png]

My guess is that this is disabled for the reason to avoid creating
non-linear history for standard PRs (as oppose to technical problem). But
this is only my guess, it would be great if someone could confirm.

Best,
Chiyuan

On Sat, Sep 29, 2018 at 3:50 AM Carin Meier  wrote:

> I believe so, but if someone wants to confirm it would be great.
> Unfortunately, I just came down with a cold/flu so I will be out of
> communication for a bit
>
> On Fri, Sep 28, 2018 at 9:51 PM Marco de Abreu
>  wrote:
>
> > Are we sure that this is due to lacking permissions and not because of
> some
> > technical limitation? If we are certain, we can ask out mentors to
> create a
> > ticket with Apache Infra to make that switch.
> >
> > -Marco
> >
> > Carin Meier  schrieb am Sa., 29. Sep. 2018, 01:17:
> >
> > > I made a test regular merge commit into a copy of master. It seemed to
> go
> > > fine. Here is a listing of what it will look like for everyone.
> > >
> > >
> >
> https://github.com/apache/incubator-mxnet/commits/test-merge-julia-import
> > >
> > > Although, I would be happy to push the merge button. I think the most
> > > important thing is to get the PR merged, so whatever way is the best to
> > > make that happen, let's do it.
> > >
> > > So - Does the regular merge seem like a good option?
> > > If so, what is the best way to make that happen?
> > >
> > >
> > > On Fri, Sep 28, 2018 at 6:05 PM Chiyuan Zhang 
> wrote:
> > >
> > > > Agreed with Pedro. Maybe the merge-commit option from the github
> > > interface
> > > > was disabled for a reason. But as Pedro said, maybe it is good to
> > > > temporarily enable it for this PR and merge using that.
> > > >
> > > >
> > > >- It should be technically easier than rebasing due to the
> > > >git-subtree-import issue we are currently having
> > > >- It also avoid stacking a huge commit history on *top* of current
> > > >history
> > > >- The downside is probably the history of the project is not
> linear
> > > >anymore, but I think this is actually what we would like to have
> for
> > > > this
> > > >particular case, because the contents of the main repo and the
> julia
> > > > branch
> > > >actually does not overlap. So it makes sense to have two tails
> with
> > > > their
> > > >own history.
> > > >
> > > > Carin: I guess if someone with admin permission on the github could
> > > > temporarily enable the merge-commit option, then pushing the button
> on
> > > the
> > > > web might simply work.
> > > >
> > > > Best,
> > > > Chiyuan
> > > >
> > > > On Fri, Sep 28, 2018 at 2:53 PM Carin Meier 
> > > wrote:
> > > >
> > > > > Pedro - Maybe a merge commit is a better answer in this case. I
> > > > originally
> > > > > ruled it out since it wasn't an option in the github web interface,
> > but
> > > > > since this looks like it is going to have to be done outside it
> > because
> > > > of
> > > > > the subtrees anyway, it might be a better fit.
> > > > >
> > > > > On Fri, Sep 28, 2018 at 5:07 PM Carin Meier 
> > > > wrote:
> > > > >
> > > > > > We are actually running into troubles with using the subtree and
> > the
> > > > > > rebase. Since it looks like this is not going to be a simple,
> > "click
> > > > the
> > > > > > button" through the web page merge, I rather hand this task off
> to
> > > > > someone
> > > > > > with more context in making sure it gets in there correctly.
> > > > > >
> > > > > > Chiyuan or any others, would you be willing to take this over?
> > > > > >
> > > > > > Thanks,
> > > > > > Carin
> > > > > >
> > > > > > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  >
> > > > wrote:
> > > > > >
> > > > > >> Should we try to first being into a branch and then try merge
> that
> > > > > >> branch?
> >

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

Agreed with Pedro. Maybe the merge-commit option from the github interface
was disabled for a reason. But as Pedro said, maybe it is good to
temporarily enable it for this PR and merge using that.


   - It should be technically easier than rebasing due to the
   git-subtree-import issue we are currently having
   - It also avoid stacking a huge commit history on *top* of current
   history
   - The downside is probably the history of the project is not linear
   anymore, but I think this is actually what we would like to have for this
   particular case, because the contents of the main repo and the julia branch
   actually does not overlap. So it makes sense to have two tails with their
   own history.

Carin: I guess if someone with admin permission on the github could
temporarily enable the merge-commit option, then pushing the button on the
web might simply work.

Best,
Chiyuan

On Fri, Sep 28, 2018 at 2:53 PM Carin Meier  wrote:

> Pedro - Maybe a merge commit is a better answer in this case. I originally
> ruled it out since it wasn't an option in the github web interface, but
> since this looks like it is going to have to be done outside it because of
> the subtrees anyway, it might be a better fit.
>
> On Fri, Sep 28, 2018 at 5:07 PM Carin Meier  wrote:
>
> > We are actually running into troubles with using the subtree and the
> > rebase. Since it looks like this is not going to be a simple, "click the
> > button" through the web page merge, I rather hand this task off to
> someone
> > with more context in making sure it gets in there correctly.
> >
> > Chiyuan or any others, would you be willing to take this over?
> >
> > Thanks,
> > Carin
> >
> > On Fri, Sep 28, 2018 at 5:00 PM Naveen Swamy  wrote:
> >
> >> Should we try to first being into a branch and then try merge that
> >> branch?
> >>
> >> > On Sep 28, 2018, at 4:40 PM, Pedro Larroy <
> pedro.larroy.li...@gmail.com>
> >> wrote:
> >> >
> >> > I'm not familiar with the specifics of this contribution, as a general
> >> > approach my understanding is that if the list of commits is big and
> you
> >> > want to preserve history, usually merging is better so you keep
> history
> >> and
> >> > causality, if you rebase all the commits on top of master you are
> >> changing
> >> > the history of these commits which can't be individually reverted as
> >> some
> >> > have suggested before. Maybe is because I come from a mercurial
> >> background,
> >> > but my initial impression would be either to:
> >> > 1. squash everything and rebase
> >> > 2. or merge without rebasing or squashing.
> >> >
> >> > Pedro.
> >> >
> >> >> On Thu, Sep 27, 2018 at 3:10 PM Carin Meier 
> >> wrote:
> >> >>
> >> >> Thanks everyone for the input. I'll try to summarize the feedback
> from
> >> the
> >> >> responses:
> >> >>
> >> >> Using Squash-Merge is the project standard for very good reasons.
> >> However,
> >> >> in the case of this PR to bring in the Julia language from its
> sibling
> >> >> repo, we want to preserve all the individual commits of the many
> >> >> contributors that have worked over multiple years to make this a
> great
> >> >> language binding. We will use Rebase-Merge for it.
> >> >>
> >> >> Chiyuan - thanks for the suggestion of using a tag. I think we can
> try
> >> it
> >> >> initially without it since there are other ways to browse the commit
> >> >> history, like looking at the PRs. But, we can add the tag
> >> retroactively if
> >> >> people start having trouble.
> >> >>
> >> >> If there no objections, I will merge the PR using the above method in
> >> my
> >> >> morning (EST).
> >> >>
> >> >> Thanks everyone! I'm looking forward to having the Julia community
> >> join the
> >> >> main repo and increasing our collaboration with them.
> >> >>
> >> >> Best,
> >> >> Carin
> >> >>
> >> >>> On Thu, Sep 27, 2018 at 1:37 PM Chiyuan Zhang 
> >> wrote:
> >> >>>
> >> >>> +1 for rebase and merge. As a workaround for the aforementioned
> issue,
> >> >>> maybe we can create a tag for the commit before the merge, so that
> in
> >> >> case
> >> >>>

Re: Which merge option to use on the Import Julia binding PR?

[Chiyuan Zhang]

Hi Carin,

Can you clarify the pros and cons of the two approaches? Is the main
concern here about logistics (e.g. preserving the history of the original
repo and developments) or technical issue (e.g. using squash might end up
with a hge commit message that might be difficult or hard to handle)?

I think it might not be very likely that someone is going to cherry pick
revert some of the commits. But preserving the commit history is still
useful in case one need to trace the change or bisect for some regression
bugs, etc.

Just to provide some context: the PR actually contains 700+ commits, and it
dates back to 2015. The development of the Julia binding started in the
early stage of MXNet. We started with a separate repo due to the
requirement of the package system of julia.

Best,
Chiyuan

On Wed, Sep 26, 2018 at 3:41 PM Carin Meier  wrote:

> The Import Julia binding PR ,(
> https://github.com/apache/incubator-mxnet/pull/10149), is getting very
> close to being merged. Because of the large number of commits there was a
> suggestion not to use the usual "Squash and Merge".  The only option would
> be "Rebase and Merge" since merging with a merge commit is not enabled for
> the project.
>
> *Squash and Merge* - The commits from this branch will be combined into one
> commit in the base branch (With all the commit messages combined)
>
> *Rebase and Merge* - The commits from this branch will be rebased and added
> to the base branch
>
> The PR is over 250+ commits (Github won't show all of them)
>
> Thoughts about how we should handle the merge?
>
> Thanks,
> Carin
>

Re: MXNet Name Change?

[Chiyuan Zhang]

IIRC CNTK renamed to something like brainscript which does not seem to be
very successful publicity campaign?

Chiyuan

On Wed, Apr 11, 2018 at 10:18 AM Chris Olivier 
wrote:

> Should we consider renaming MXNet to something more "friendly"?
>
> IMHO, I think this may be related to adoption problems.
>
> MXNet, CMTK -- both seem sort of sterile and hard to use, don't they?
>
> Tensorflow, PyTorch, Caffe -- sound cool.
>
-- 
Semt ftom m ipohne

Re: Formalize Committer Proposal and Application Procedure

[Chiyuan Zhang]

On Fri, Aug 4, 2017 at 1:04 PM, Isabel Drost-Fromm <isa...@apache.org>
wrote:

> On Fri, Aug 04, 2017 at 12:27:16PM +0100, Chiyuan Zhang wrote:
> > Suppose we lower the standard or completely remove the formal standard
> for
> > committers, then we could probably be able to get more committers from
> the
> > first type. But that might not necessarily be good to us
>
> Can you elaborate your reasoning here? (I'm not implying that I agree or
> disagree with you, I just want to understand where this fear is coming
> from.)
>
>
I think this depends on what committers could do (writing permission to the
repo? voting in decisions for the direction of the projects? etc.). Another
thing might be that having too many committers makes it less valuable to
become a committer and therefore discourage new people.


>
> > having people that could either contribute relatively important
> components
> > or provide longer term commitment to the project. But on the other hand,
> > having a standard for committers do not (I hope) discourage the first
> type
> > of contributors to contribute PRs.
>
> Let me tell you a little campfire story: Back in the old days of Mahout we
> implicitly had a relatively high bar for becoming a committer. People
> thought
> that in order to become committer they would have to contribute substantial
> patches, often full new algorithm implementations.
>
> What the project really needed were a lot of work polishing, optimising,
> cleaning, making easier to use, documenting etc.
>
> Due to the perception of requiring substantial contributions to get the
> reward of becoming committer however we never received much of the latter.
>

Yes, I totally agree that open source project survival really needs
continuous contributions from the committee and many maintenance and
polishing work. I would like to re-state that I support having a *clear*
policy or guideline for becoming committers, not necessarily one with very
high bar that requires substantial contributions. I think if we are able to
control the guidelines to a reasonable level and easy to follow and get
started, then this might even encourage new users to contribute.

chiyuan


>
>
> Lesson learnt for me: The way you setup your reward systems greatly
> influences which kind of help your project will receive.
>
>
> Isabel
>
> --
> Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most
> likely involving some kind of mobile connection only.)
>

Re: Formalize Committer Proposal and Application Procedure

[Chiyuan Zhang]

Hi all, just want to share my bits. I like the idea of formalizing the
committer proposal mechanism. The actual standard for what count as good
enough for a committer could be discussed.

I think the worrying of not being able to recruit new committers might not
be a serious problem. I am thinking about two types of people here

1. There are some people who contribute to MXNet due to something else
(e.g. he used MXNet in his project and would like to contribute back
examples, or bug fix, or new operators, etc.)

2. There are some people who is interested in MXNet development and would
like to work on it for a relatively long term (maintaining or developing)
or would like to work on a relatively major component.

My point is that for the first type of contributors, we might not need to
propose everyone of them as Apache committers (if I understand correctly,
everyone can submit a PR, even without committer permission, right?). On
the other hand, the second type of contributors are our main target for
committers, and I think for those people, having a more clear standard
(again the actual standard could be debatable) for committer would not be a
huge barrier.

Suppose we lower the standard or completely remove the formal standard for
committers, then we could probably be able to get more committers from the
first type. But that might not necessarily be good to us --- in terms of
having people that could either contribute relatively important components
or provide longer term commitment to the project. But on the other hand,
having a standard for committers do not (I hope) discourage the first type
of contributors to contribute PRs.

Best,
Chiyuan

On Fri, Aug 4, 2017 at 8:42 AM, Henri Yandell  wrote:

> I worry that it creates a high barrier to entry.
>
> It's a far more common pattern for a project to do poorly at recruiting new
> committers, than it is for one to recruit too many.
>
> Could you provide an example that provides a likely (imaginary if you'd
> like) candidate? Mu's a pretty bad example for a new committer :) From the
> attached doc I walk away thinking that I need to contribute for 2 years
> before I can become a committer.
>
> Hen
>
> On Thu, Aug 3, 2017 at 9:49 AM, Ziheng Jiang  wrote:
>
> > Forward my comment in private mail list:
> >
> > I agree that it would be nice to have some quantitative standards to
> > evaluate the candidates. Let's encourage the future candidates do this.
> >
> > - Ziheng
> >
> > On Thu, Aug 3, 2017 at 09:44 Mu Li  wrote:
> >
> > > It seems that this thread didn't show in the dev list.
> > >
> > > Totally agree that we should make the committer nomination more formal.
> > >
> > > -- Forwarded message --
> > > From: Tianqi Chen 
> > > Date: Wed, Aug 2, 2017 at 4:20 PM
> > > Subject: Formalize Committer Proposal and Application Procedure
> > > To: priv...@mxnet.incubator.apache.org
> > >
> > >
> > > Hi Guys:
> > >  As I mentioned in another thread, I personally think the current
> > > committer proposal and application process is too informal.
> > >  As MXNet grows larger and the community involves, I think it would
> > be
> > > very helpful to formalize the process and provide a clear standard for
> > what
> > > are we looking for in the comitter proposal process, and allow us to
> > > evaluate based on the concrete evidence listed in the application to
> > > promote the comitters.
> > >  This will setup a good standard for the contributors, as well as
> > > provide solid material to back our decisions. After did some search, I
> > > created this application template based on the committer application
> from
> > > Apache Mesos. I wrote it from the perspective of myself.
> > >  https://docs.google.com/document/d/1vKTgX1_EkAT7NSmaiBKBmbq
> > > DuhF9kQd53BB4iUxGn4M/edit?usp=sharing
> > >
> > >  I would recommend this to become the mandatory thing for the
> future
> > > committer nomination and voting, as well as the re-evaluation standard
> of
> > > current comitters when we graduate from the incubator project.
> > >
> > > Tianqi
> > >
> > --
> > Ziheng Jiang
> > Fudan University | Computer Science
> >
>

Re: building mxnet.io from release tag

[Chiyuan Zhang]

We can provide versioned docs. AFAIK Sphinx support docs of different
versions (see e.g. the top left corner for switch between versions of docs
for Python here: https://docs.python.org/2/library/index.html ). So we can
have a "latest" doc and a few history versioned doc that is to be built
whenever we make a new release.

- chiyuan

On Wed, May 17, 2017 at 1:47 PM, Naveen Swamy  wrote:

> If we have a regular and frequent release cadence, then building mxnet.io
> would be good.
> Since our releases are not that frequent, I am not very inclined to wait
> for a release candidate to get new tutorials/howtos onto the website. that
> being said we can restrict to build tutorials/howtos/other sections., from
> tip of the master and API documentation to come from a release tag.
>
> -Naveen
>
>
>
> On Wed, May 17, 2017 at 10:05 AM, Madan Jampani 
> wrote:
>
> > We are currently building mxnet.io directly from HEAD of master.
> > With the next release we should make sure mxnet.io is built from a
> release
> > tag. This will ensure the docs website reflects the latest stable
> release.
> >
> > Any one disagrees?
> >
> > Madan.
> >
>