+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
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 <
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
> One of the main reason for a rebase merge is that it preserves the
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
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?
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
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
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.
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
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
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
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
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
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
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?
On Tue, Sep 4, 2018
On Tue, Sep 25, 2018 at 10:29 PM Vikas Kumar wrote:
> Please send me an invite to join.
Mail list logo