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

[Aaron Markham]

+1 to rebase and merge to retain the efforts of all of the contributors. If
there's some git maintenance that can trim it down from 700+ commits then
maybe that's a compromise.

On Wed, Sep 26, 2018, 21:23 Naveen Swamy  wrote:

> this PR comes from more than 1 individual, if we squash merge we'll not be
> able to attribute the contribution of those individuals.
>
> +1 to rebase merge to preserve history
>
> On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
> wrote:
>
> > One of the main reason for a rebase merge is that it preserves the commit
> > history of the MXNet.jl package contributors, and given that the project
> > has been evolved since 2015 and has always been a high-quality language
> > module for MXNet.
> >
> > I think we should take an exception here to preserve the commit history
> of
> > each individual contributors to the Julia binding and welcome them to the
> > community.
> >
> > Tianqi
> >
> > On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> > wrote:
> >
> > > In this particular case, I would suggest rebase and merge.
> > >
> > > The main reasoning is that the commit log of the Julia binding is not
> > > simple WIP commits, every commit there has been done through testcases
> > and
> > > it is important for us to respect the developer of the effort. It is
> also
> > > good to trace back the history of the commits more easily.
> > >
> > > Tianqi
> > >
> > >
> > > Tianqi
> > >
> > > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> > wrote:
> > >
> > >> Chiyuan,
> > >>
> > >> Thanks for the prompt to find some clarity of the pros and cons of
> > each. I
> > >> think that will help drive us to the right decision. I think some of
> > those
> > >> reasons are the ones you listed. I will take a stab below at outlining
> > >> what
> > >> I see. Feel free to chime in if I missed any.
> > >>
> > >> *Squash and Merge*
> > >>   *Pros* - It is the project standard
> > >>   - It will provide one commit for the feature and lessen the
> > need
> > >> for 700+ commits rebased on top of master.
> > >>  - It is easier for a user to do git log to browse commits and
> > see
> > >> what was features were added.
> > >>   *Cons* - I don't know how github would handle squashing all those
> > commit
> > >> messages into one. Will it be too much?
> > >> - You lose the granularity of the features individual
> > commits
> > >>
> > >> *Rebase and Merge*
> > >>  * Pros *- You don't have a huge commit message with one commit
> > >>   -  You do have the granularity of the individual features of
> > the
> > >> commit
> > >>  * Cons *- It is not the project standard
> > >>- You have 700+ commits on top of master that might be
> harder
> > >> to
> > >> see the ones that went in right before. (like someone browsing
> commits)
> > >>
> > >> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang 
> > wrote:
> > >>
> > >> > 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: Requesting slack access

[Naveen Swamy]

Invite sent. Welcome to Apache MXNet, we have a forum for questions related
to MXNet https://discuss.mxnet.io/ and in-depth tutorial on getting started
with MXNet https://gluon.mxnet.io/, feel free to ask questions


On Thu, Sep 27, 2018 at 12:04 AM, Rahul Padmanabhan <
rahul.padmanab...@gmail.com> wrote:

> Hello,
>
> I’m Rahul Padmanabhan, a Data Scientist in Montreal. I code in Python (and
> Scala sometimes) and am interested in contributing to the development of
> MXNet. Could you please add me to the MXNet Slack Channel?
>
> Thanks!
> Rahul Padmanabhan

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

[Naveen Swamy]

this PR comes from more than 1 individual, if we squash merge we'll not be
able to attribute the contribution of those individuals.

+1 to rebase merge to preserve history

On Thu, Sep 27, 2018 at 12:04 AM, Tianqi Chen 
wrote:

> One of the main reason for a rebase merge is that it preserves the commit
> history of the MXNet.jl package contributors, and given that the project
> has been evolved since 2015 and has always been a high-quality language
> module for MXNet.
>
> I think we should take an exception here to preserve the commit history of
> each individual contributors to the Julia binding and welcome them to the
> community.
>
> Tianqi
>
> On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
> wrote:
>
> > In this particular case, I would suggest rebase and merge.
> >
> > The main reasoning is that the commit log of the Julia binding is not
> > simple WIP commits, every commit there has been done through testcases
> and
> > it is important for us to respect the developer of the effort. It is also
> > good to trace back the history of the commits more easily.
> >
> > Tianqi
> >
> >
> > Tianqi
> >
> > On Wed, Sep 26, 2018 at 5:34 PM Carin Meier 
> wrote:
> >
> >> Chiyuan,
> >>
> >> Thanks for the prompt to find some clarity of the pros and cons of
> each. I
> >> think that will help drive us to the right decision. I think some of
> those
> >> reasons are the ones you listed. I will take a stab below at outlining
> >> what
> >> I see. Feel free to chime in if I missed any.
> >>
> >> *Squash and Merge*
> >>   *Pros* - It is the project standard
> >>   - It will provide one commit for the feature and lessen the
> need
> >> for 700+ commits rebased on top of master.
> >>  - It is easier for a user to do git log to browse commits and
> see
> >> what was features were added.
> >>   *Cons* - I don't know how github would handle squashing all those
> commit
> >> messages into one. Will it be too much?
> >> - You lose the granularity of the features individual
> commits
> >>
> >> *Rebase and Merge*
> >>  * Pros *- You don't have a huge commit message with one commit
> >>   -  You do have the granularity of the individual features of
> the
> >> commit
> >>  * Cons *- It is not the project standard
> >>- You have 700+ commits on top of master that might be harder
> >> to
> >> see the ones that went in right before. (like someone browsing commits)
> >>
> >> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang 
> wrote:
> >>
> >> > 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: Which merge option to use on the Import Julia binding PR?

[Tianqi Chen]

One of the main reason for a rebase merge is that it preserves the commit
history of the MXNet.jl package contributors, and given that the project
has been evolved since 2015 and has always been a high-quality language
module for MXNet.

I think we should take an exception here to preserve the commit history of
each individual contributors to the Julia binding and welcome them to the
community.

Tianqi

On Wed, Sep 26, 2018 at 8:55 PM Tianqi Chen 
wrote:

> In this particular case, I would suggest rebase and merge.
>
> The main reasoning is that the commit log of the Julia binding is not
> simple WIP commits, every commit there has been done through testcases and
> it is important for us to respect the developer of the effort. It is also
> good to trace back the history of the commits more easily.
>
> Tianqi
>
>
> Tianqi
>
> On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  wrote:
>
>> Chiyuan,
>>
>> Thanks for the prompt to find some clarity of the pros and cons of each. I
>> think that will help drive us to the right decision. I think some of those
>> reasons are the ones you listed. I will take a stab below at outlining
>> what
>> I see. Feel free to chime in if I missed any.
>>
>> *Squash and Merge*
>>   *Pros* - It is the project standard
>>   - It will provide one commit for the feature and lessen the need
>> for 700+ commits rebased on top of master.
>>  - It is easier for a user to do git log to browse commits and see
>> what was features were added.
>>   *Cons* - I don't know how github would handle squashing all those commit
>> messages into one. Will it be too much?
>> - You lose the granularity of the features individual commits
>>
>> *Rebase and Merge*
>>  * Pros *- You don't have a huge commit message with one commit
>>   -  You do have the granularity of the individual features of the
>> commit
>>  * Cons *- It is not the project standard
>>- You have 700+ commits on top of master that might be harder
>> to
>> see the ones that went in right before. (like someone browsing commits)
>>
>> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:
>>
>> > 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
>> > >
>> >
>>
>

Requesting slack access

[Rahul Padmanabhan]

Hello,

I’m Rahul Padmanabhan, a Data Scientist in Montreal. I code in Python (and 
Scala sometimes) and am interested in contributing to the development of MXNet. 
Could you please add me to the MXNet Slack Channel?

Thanks!
Rahul Padmanabhan

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

[Tianqi Chen]

In this particular case, I would suggest rebase and merge.

The main reasoning is that the commit log of the Julia binding is not
simple WIP commits, every commit there has been done through testcases and
it is important for us to respect the developer of the effort. It is also
good to trace back the history of the commits more easily.

Tianqi


Tianqi

On Wed, Sep 26, 2018 at 5:34 PM Carin Meier  wrote:

> Chiyuan,
>
> Thanks for the prompt to find some clarity of the pros and cons of each. I
> think that will help drive us to the right decision. I think some of those
> reasons are the ones you listed. I will take a stab below at outlining what
> I see. Feel free to chime in if I missed any.
>
> *Squash and Merge*
>   *Pros* - It is the project standard
>   - It will provide one commit for the feature and lessen the need
> for 700+ commits rebased on top of master.
>  - It is easier for a user to do git log to browse commits and see
> what was features were added.
>   *Cons* - I don't know how github would handle squashing all those commit
> messages into one. Will it be too much?
> - You lose the granularity of the features individual commits
>
> *Rebase and Merge*
>  * Pros *- You don't have a huge commit message with one commit
>   -  You do have the granularity of the individual features of the
> commit
>  * Cons *- It is not the project standard
>- You have 700+ commits on top of master that might be harder to
> see the ones that went in right before. (like someone browsing commits)
>
> On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:
>
> > 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: Which merge option to use on the Import Julia binding PR?

[Afrooze, Sina]

Hi Carin - I highly recommend to squash and commit because:
- Every single commit in the repo is guaranteed to be buildable and to have 
passed all unit-tests (very important when looking for regressions)
- It is easy to correlate each commit with its corresponding PR. Otherwise I 
believe the PR number would be missing from the commit log messages.

- Best, Sina

On 9/26/18, 5:35 PM, "Carin Meier"  wrote:

Chiyuan,

Thanks for the prompt to find some clarity of the pros and cons of each. I
think that will help drive us to the right decision. I think some of those
reasons are the ones you listed. I will take a stab below at outlining what
I see. Feel free to chime in if I missed any.

*Squash and Merge*
  *Pros* - It is the project standard
  - It will provide one commit for the feature and lessen the need
for 700+ commits rebased on top of master.
 - It is easier for a user to do git log to browse commits and see
what was features were added.
  *Cons* - I don't know how github would handle squashing all those commit
messages into one. Will it be too much?
- You lose the granularity of the features individual commits

*Rebase and Merge*
 * Pros *- You don't have a huge commit message with one commit
  -  You do have the granularity of the individual features of the
commit
 * Cons *- It is not the project standard
   - You have 700+ commits on top of master that might be harder to
see the ones that went in right before. (like someone browsing commits)

On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:

> 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: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Chiyuan,

Thanks for the prompt to find some clarity of the pros and cons of each. I
think that will help drive us to the right decision. I think some of those
reasons are the ones you listed. I will take a stab below at outlining what
I see. Feel free to chime in if I missed any.

*Squash and Merge*
  *Pros* - It is the project standard
  - It will provide one commit for the feature and lessen the need
for 700+ commits rebased on top of master.
 - It is easier for a user to do git log to browse commits and see
what was features were added.
  *Cons* - I don't know how github would handle squashing all those commit
messages into one. Will it be too much?
- You lose the granularity of the features individual commits

*Rebase and Merge*
 * Pros *- You don't have a huge commit message with one commit
  -  You do have the granularity of the individual features of the
commit
 * Cons *- It is not the project standard
   - You have 700+ commits on top of master that might be harder to
see the ones that went in right before. (like someone browsing commits)

On Wed, Sep 26, 2018 at 8:12 PM Chiyuan Zhang  wrote:

> 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: 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: Which merge option to use on the Import Julia binding PR?

[Carin Meier]

Kellen,

Thanks for your input. We can certainly try squash and merge and see if
there are any issues.

My inclination is same as yours in the case of the git rework, but I'm not
sure how feasible it is since commits go back to Jan 2017 - It's bringing
in this repo work I believe https://github.com/dmlc/MXNet.jl.

Here is an example of the first commit in the PR
Commits on Jan 29, 2017

   1.

   Merge pull request
   

#196  from
   dmlc/vc/fix_win
   

…
   [image: @vchuravy] 
   vchuravy
   
committed on Jan 29, 2017

   remove usr/setupenv.cmd because it is too invasive



On Wed, Sep 26, 2018 at 7:15 PM kellen sunderland <
kellen.sunderl...@gmail.com> wrote:

> My gut feel would be just to squash and merge, it usually works quite well.
>
> Is there any chance that someone might want to cherry-pick, revert or
> rebase any portions of the PR?
>
> If so what I try and is to provide atomic commits the bring small
> individual pieces of value to the codebase.  This often means at the end of
> the PR I'd do some git hygiene, get rework my commits and then force push.
> I try to ensure that I also leave a backup branch in GitHub that contains
> my original git history.  If you have an atomic chain of commits then it
> might make more sense to rebase and merge.
>
> On Wed, Sep 26, 2018, 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: Which merge option to use on the Import Julia binding PR?

[kellen sunderland]

My gut feel would be just to squash and merge, it usually works quite well.

Is there any chance that someone might want to cherry-pick, revert or
rebase any portions of the PR?

If so what I try and is to provide atomic commits the bring small
individual pieces of value to the codebase.  This often means at the end of
the PR I'd do some git hygiene, get rework my commits and then force push.
I try to ensure that I also leave a backup branch in GitHub that contains
my original git history.  If you have an atomic chain of commits then it
might make more sense to rebase and merge.

On Wed, Sep 26, 2018, 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
>

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

[Carin Meier]

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

Maturity Model and Graduation

[Jim Jagielski]

As a newly "minted" mentor, I'm getting my feet wet on determining where the 
project is and where it needs to go in order to be ready for graduation...

Has the project run the Maturity Model against itself? How do we stack up? What 
areas of improvement could we benefit from (this might be independent of what 
the MatModel sez, btw. If you have ideas on where we could be working and 
collaborating better, please bring them up!)?

Cheers!

Re: [LAZY VOTE] Consolidating developer guide in one place (cwiki preferred)

[Aaron Markham]

I think the latest feedback has been great. It seems to be mostly user
level issues though. Installation and usage primarily, with a sprinkle of
*if that stuff was better then I might be able to contribute*.

I've (with a few other contributors) tackled some of the very direct bits
of feedback for the website by incremental improvement of the install
pages, Gluon info, and UX for the API docs.

I've started additional planning for updates by adding an epic with
specific stories and tasks to Jira for the documentation pipeline (the
backend part of the website build):
https://issues.apache.org/jira/browse/MXNET-957

I've also added one that is more specific to the website's content:
https://issues.apache.org/jira/browse/MXNET-986
This is where I've captured only two tasks related to transitioning content
related to "contributing to MXNet" over to the wiki. Any pointers on which
content to move would help. These could be added as tasks too.

I welcome any suggestions, additions, and contributions to either of these
epics.

Cheers,
Aaron

On Wed, Sep 26, 2018, 00:02 Lin Yuan  wrote:

> Hi Aaron,
>
> Do we have a resolution for this proposal yet? Recently, there have been
> many asks for a better documentation for MXNet developers. I think it's a
> good time that we consolidate the developer documentation in a central
> place. Any thoughts or plan?
>
> Many Thanks,
>
> Lin
>
> On Tue, Sep 4, 2018 at 1:55 PM Lin Yuan  wrote:
>
> > +1
> >
> > On Tue, Sep 4, 2018 at 1:46 PM Aaron Markham 
> > wrote:
> >
> >> I'd like to call for a lazy vote on this before proceeding. Already had
> >> some +1s but let's be sure.
> >>
> >> The vote is to move developer guide info to cwiki. User guides would
> >> remain
> >> on the website.
> >>
> >> On Tue, Aug 21, 2018 at 12:53 PM sandeep krishnamurthy <
> >> sandeep.krishn...@gmail.com> wrote:
> >>
> >> > +1
> >> > Thanks Lin and Aaron. I agree website to cover all user facing
> >> > documentation and a separate consolidated and organized developer
> >> focussed
> >> > docs in one place (cwiki).
> >> >
> >> >
> >> > Note: Permissions on cwiki is currently not well managed with many
> >> people
> >> > having full admin rights to edit/create/delete pages. Should be fine
> for
> >> > now, but, when we start accumulating many documents and resources, we
> >> > should probably revisit on Delete permissions.
> >> >
> >> >
> >> > On Tue, Aug 21, 2018 at 11:57 AM Lin Yuan 
> wrote:
> >> >
> >> > > Hi Aaron,
> >> > >
> >> > > Thanks for your answer. I think it's a very worthwhile effort to
> move
> >> all
> >> > > the developer related content from mxet.io website to a dedicated
> >> > > developer
> >> > > site. Would you like to initiate this effort?
> >> > >
> >> > > Best,
> >> > >
> >> > > Lin
> >> > >
> >> > > On Wed, Aug 15, 2018 at 3:47 PM Haibin Lin <
> haibin.lin@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > +1
> >> > > >
> >> > > > On Wed, Aug 15, 2018 at 1:10 PM, Aaron Markham <
> >> > > aaron.s.mark...@gmail.com>
> >> > > > wrote:
> >> > > >
> >> > > > > Hi Lin, I agree with this organization. If you feel like
> >> somethings
> >> > > > should
> >> > > > > be transitioned from the website to the wiki, I can help with
> >> that,
> >> > but
> >> > > > for
> >> > > > > the moment I've been suggesting that new developer-focused
> >> content be
> >> > > > > placed on the wiki.
> >> > > > >
> >> > > > > On Tue, Aug 14, 2018 at 10:40 AM, Lin Yuan  >
> >> > > wrote:
> >> > > > >
> >> > > > > > Dear MXNet community,
> >> > > > > >
> >> > > > > > As a developer, I noticed we have some developer guide
> >> scattered in
> >> > > > > > different websites (mxnet.io, cwiki):
> >> > > > > >
> >> > > > > > E.g.
> >> > > > > >
> >> > > > > > How to Create New Operators (Layers): [
> >> > > > > > https://mxnet.incubator.apache.org/faq/new_op.html]
> >> > > > > > A Guide to Implementing Sparse Operators in MXNet Backend [
> >> > > > > > https://cwiki.apache.org/confluence/display/MXNET/A+
> >> > > > > > Guide+to+Implementing+Sparse+Operators+in+MXNet+Backend
> >> > > > > > ]
> >> > > > > >
> >> > > > > > When searching developer guide by keyword, only one of them
> can
> >> be
> >> > > > > returned
> >> > > > > > on either site.
> >> > > > > >
> >> > > > > > It will be more convenient for developers if all the developer
> >> > guide
> >> > > > > > resides on cwiki and all user guide (non-developer) on the
> >> > mxnet.io
> >> > > > > > website. We can add a link on mxnet.io to refer all
> developers
> >> to
> >> > > > cwiki
> >> > > > > > for
> >> > > > > > guidance.
> >> > > > > >
> >> > > > > > Any comment is appreciated.
> >> > > > > >
> >> > > > > > Best Regards,
> >> > > > > >
> >> > > > > > Lin
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Sandeep Krishnamurthy
> >> >
> >>
> >
>

Re: [LAZY VOTE] Consolidating developer guide in one place (cwiki preferred)

[Lin Yuan]

Hi Aaron,

Do we have a resolution for this proposal yet? Recently, there have been
many asks for a better documentation for MXNet developers. I think it's a
good time that we consolidate the developer documentation in a central
place. Any thoughts or plan?

Many Thanks,

Lin

On Tue, Sep 4, 2018 at 1:55 PM Lin Yuan  wrote:

> +1
>
> On Tue, Sep 4, 2018 at 1:46 PM Aaron Markham 
> wrote:
>
>> I'd like to call for a lazy vote on this before proceeding. Already had
>> some +1s but let's be sure.
>>
>> The vote is to move developer guide info to cwiki. User guides would
>> remain
>> on the website.
>>
>> On Tue, Aug 21, 2018 at 12:53 PM sandeep krishnamurthy <
>> sandeep.krishn...@gmail.com> wrote:
>>
>> > +1
>> > Thanks Lin and Aaron. I agree website to cover all user facing
>> > documentation and a separate consolidated and organized developer
>> focussed
>> > docs in one place (cwiki).
>> >
>> >
>> > Note: Permissions on cwiki is currently not well managed with many
>> people
>> > having full admin rights to edit/create/delete pages. Should be fine for
>> > now, but, when we start accumulating many documents and resources, we
>> > should probably revisit on Delete permissions.
>> >
>> >
>> > On Tue, Aug 21, 2018 at 11:57 AM Lin Yuan  wrote:
>> >
>> > > Hi Aaron,
>> > >
>> > > Thanks for your answer. I think it's a very worthwhile effort to move
>> all
>> > > the developer related content from mxet.io website to a dedicated
>> > > developer
>> > > site. Would you like to initiate this effort?
>> > >
>> > > Best,
>> > >
>> > > Lin
>> > >
>> > > On Wed, Aug 15, 2018 at 3:47 PM Haibin Lin 
>> > > wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On Wed, Aug 15, 2018 at 1:10 PM, Aaron Markham <
>> > > aaron.s.mark...@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > Hi Lin, I agree with this organization. If you feel like
>> somethings
>> > > > should
>> > > > > be transitioned from the website to the wiki, I can help with
>> that,
>> > but
>> > > > for
>> > > > > the moment I've been suggesting that new developer-focused
>> content be
>> > > > > placed on the wiki.
>> > > > >
>> > > > > On Tue, Aug 14, 2018 at 10:40 AM, Lin Yuan 
>> > > wrote:
>> > > > >
>> > > > > > Dear MXNet community,
>> > > > > >
>> > > > > > As a developer, I noticed we have some developer guide
>> scattered in
>> > > > > > different websites (mxnet.io, cwiki):
>> > > > > >
>> > > > > > E.g.
>> > > > > >
>> > > > > > How to Create New Operators (Layers): [
>> > > > > > https://mxnet.incubator.apache.org/faq/new_op.html]
>> > > > > > A Guide to Implementing Sparse Operators in MXNet Backend [
>> > > > > > https://cwiki.apache.org/confluence/display/MXNET/A+
>> > > > > > Guide+to+Implementing+Sparse+Operators+in+MXNet+Backend
>> > > > > > ]
>> > > > > >
>> > > > > > When searching developer guide by keyword, only one of them can
>> be
>> > > > > returned
>> > > > > > on either site.
>> > > > > >
>> > > > > > It will be more convenient for developers if all the developer
>> > guide
>> > > > > > resides on cwiki and all user guide (non-developer) on the
>> > mxnet.io
>> > > > > > website. We can add a link on mxnet.io to refer all developers
>> to
>> > > > cwiki
>> > > > > > for
>> > > > > > guidance.
>> > > > > >
>> > > > > > Any comment is appreciated.
>> > > > > >
>> > > > > > Best Regards,
>> > > > > >
>> > > > > > Lin
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> >
>> > --
>> > Sandeep Krishnamurthy
>> >
>>
>