This vote is for the code-change of altering the Scala API namespace from
dmlc to org.apache.
Vote will conclude on Thursday, 5pm PDT.
Thank you,
-Chris
I think we'd specify it will change in the next version (1.2)?
On Mon, Mar 12, 2018 at 9:26 AM, Chris Olivier
wrote:
> This vote is for the code-change of altering the Scala API namespace from
> dmlc to org.apache.
>
>
> Vote will conclude on Thursday, 5pm PDT.
>
> Thank you,
>
> -Chris
>
It has been proposed that all Non-C API's follow separate versioning from
the main mxnet C API/releases.
A +1 vote is in *favor of* using a different versioning for all
non-C-API's, with each API (Scala, R, Julia, C++, etc.) having its own
version.
A -1 vote is *against* using a different version
+1
On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier
wrote:
> It has been proposed that all Non-C API's follow separate versioning from
> the main mxnet C API/releases.
>
> A +1 vote is in *favor of* using a different versioning for all
> non-C-API's, with each API (Scala, R, Julia, C++, etc.) havi
Release versioning is a separate issue or vote. At release time, people
can "demand" version X or Y. This vote represents "do we want to change
the namespace".
On Mon, Mar 12, 2018 at 9:30 AM, Nan Zhu wrote:
> I think we'd specify it will change in the next version (1.2)?
>
>
> On Mon, Mar 12,
+1
Tianqi Chen schrieb am Mo., 12. März 2018, 17:33:
> +1
>
> On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier
> wrote:
>
> > It has been proposed that all Non-C API's follow separate versioning from
> > the main mxnet C API/releases.
> >
> > A +1 vote is in *favor of* using a different versionin
+1 for changing the namespace
-1 for merging this change into master according to the current policy
Chris Olivier schrieb am Mo., 12. März 2018, 17:34:
> Release versioning is a separate issue or vote. At release time, people
> can "demand" version X or Y. This vote represents "do we want to
+1
On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> +1
>
> Tianqi Chen schrieb am Mo., 12. März 2018,
> 17:33:
>
> > +1
> >
> > On Mon, Mar 12, 2018 at 9:32 AM, Chris Olivier
> > wrote:
> >
> > > It has been proposed that all Non-C API's follow separate
Are you saying your vote is contingent upon the outcome of a separate vote?
On Mon, Mar 12, 2018 at 9:37 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> +1 for changing the namespace
> -1 for merging this change into master according to the current policy
>
> Chris Olivier schrieb am
how about release cycle?
On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang wrote:
> +1
>
> On Mon, Mar 12, 2018 at 12:35 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > +1
> >
> > Tianqi Chen schrieb am Mo., 12. März 2018,
> > 17:33:
> >
> > > +1
> > >
> > > On Mon, Mar 12, 2018 at
Right
Chris Olivier schrieb am Mo., 12. März 2018, 17:38:
> Are you saying your vote is contingent upon the outcome of a separate vote?
>
> On Mon, Mar 12, 2018 at 9:37 AM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > +1 for changing the namespace
> > -1 for merging this change
According to the discussion in the Scala thread, the release cycles would
stay unchanged and are still part of the mxnet releases.
Nan Zhu schrieb am Mo., 12. März 2018, 17:42:
> how about release cycle?
>
>
> On Mon, Mar 12, 2018 at 9:37 AM, Yuan Tang
> wrote:
>
> > +1
> >
> > On Mon, Mar 12,
Under the current SemVer-policy, this change must not be merged into a 1.x
release branch and that's why I am downvoting. I agree that this change is
necessary in general, but it requires the other vote to pass in order to be
possible within a MXNet 1.x release.
Marco de Abreu schrieb am Mo., 12.
If you're tying this to a process issue, then it's no longer a code
modification technical vote.
On Mon, Mar 12, 2018 at 9:56 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> Right
>
> Chris Olivier schrieb am Mo., 12. März 2018,
> 17:38:
>
> > Are you saying your vote is contingent
I gave my +1 for the code modification. The -1 was for Nan Zhus proposal to
get it into 1.2.
On Mon, Mar 12, 2018 at 6:18 PM, Chris Olivier
wrote:
> If you're tying this to a process issue, then it's no longer a code
> modification technical vote.
>
>
> On Mon, Mar 12, 2018 at 9:56 AM, Marco de
Chris, Thanks for starting this vote.
This is long pending
+1 to change org.apache namespace
On Mon, Mar 12, 2018 at 10:35 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> I gave my +1 for the code modification. The -1 was for Nan Zhus proposal to
> get it into 1.2.
>
> On Mon, Mar 12
-1 for different versioning, it not only be maintenance nightmare but also
more importantly confusing to users,
On Mon, Mar 12, 2018 at 9:57 AM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:
> According to the discussion in the Scala thread, the release cycles would
> stay unchanged and
Can someone please give write me access to the MXNet wiki?
Done.
On Mon, Mar 12, 2018 at 11:27 AM Chris Olivier
wrote:
> Can someone please give write me access to the MXNet wiki?
>
STRONGLY -1 (binding) as I explained in another thread 'Publishing
Scala Package/namespace change'. I think separating version is
harmful.
1. It is harmful to user experience
1) Each time users want to use a specific feature, need to first
check the mxnet core version, then check which fronten
Regarding #4: Changing namespaces is one use-case, but there will be a lot
more with increasing activity - we have to take the bigger picture in mind.
I think it is safe to say that the other APIs have not been maintained as
actively as our Python/Gluon API (which I would say could be versioned
tog
Marco, you're mixing votes again.
* This leaves us with three options: 1. Vote failed: No refactoring of
user-facing APIs (including namespace changes) possible OR major version
increase 2. Vote succeeded: Refactoring of user-facing APIs possible and
only users of the changed APIs are aff
Please cast your vote only on the subject at hand. This is leading to
confusion and unnecessary discussion/wasting time, you can start a new
thread if you so like.
I really would want to make progress on getting the Scala API to this
release.
On Mon, Mar 12, 2018 at 2:11 PM, Chris Olivier
wrote:
Agree.
And my reply to Marco's point,
> Changing namespaces is one use-case, but there will be a lot more with
> increasing activity - we have to take the bigger picture in mind.
And you mentioned the CPP package as an example.
> During analysis, we figured that a re-engineering of that API woul
Just for clarification: Is this vote about changing the namespace with the
next release?
On Mon, Mar 12, 2018 at 7:16 PM, Naveen Swamy wrote:
> Chris, Thanks for starting this vote.
> This is long pending
>
> +1 to change org.apache namespace
>
> On Mon, Mar 12, 2018 at 10:35 AM, Marco de Abreu
It is about changing the namespace. As far as I know, the version number
of the next release is not defined.
At such point where a release is announced, one could comment, vote
whatever on the chosen version of that release, I suppose. But that's
beyond the scope of this vote, because the "next r
The assumption is that it would be changed more-or-less immediately. ie.
this is like a voted PR, I guess.
On Mon, Mar 12, 2018 at 2:53 PM, Chris Olivier
wrote:
> It is about changing the namespace. As far as I know, the version number
> of the next release is not defined.
> At such point wher
-1 for different versioning.
I feel its just added confusion for users.
On Mon, Mar 12, 2018 at 2:35 PM, YiZhi Liu wrote:
> Agree.
>
> And my reply to Marco's point,
>
> > Changing namespaces is one use-case, but there will be a lot more with
> increasing activity - we have to take the bigger p
+1 to change the namespace
On Mon, Mar 12, 2018 at 3:05 PM, Chris Olivier
wrote:
> The assumption is that it would be changed more-or-less immediately. ie.
> this is like a voted PR, I guess.
>
> On Mon, Mar 12, 2018 at 2:53 PM, Chris Olivier
> wrote:
>
> > It is about changing the namespace.
-1 for the frontends having different versions than the backend. It not
only creates confusion for new users, but also increases the work of
developers who need to ensure compatibility. All this for a one-time change
of namespace of a package?
I think we should increase the major version number to
+1
We need to change the namespace as soon as possible.
On Mon, Mar 12, 2018 at 3:15 PM, Roshani Nagmote
wrote:
> +1 to change the namespace
>
> On Mon, Mar 12, 2018 at 3:05 PM, Chris Olivier
> wrote:
>
> > The assumption is that it would be changed more-or-less immediately. ie.
> > this is l
@Rahul + Roshani, I would hear what you're saying if the user had to worry
about using the native package, but that worry is abstracted from them.
The scala package has a dependency on the native library and includes the
native lib inside the jar. The correct lib is then bound against at
runtime.
Kellen, we are not talking about using wrong native package AFTER
downloading the package. It's about deciding which version to use
BEFORE downloading, and collecting information to debug.
Copy-paste my previous words,
"
1. It is harmful to user experience
1) Each time users want to use a spe
@YiZhi Well let's agree to disagree on this one I guess. There's some
pretty strong -1s here, and this is clearly a code change so I think it's
good that we had the vote and can move past the issue. I'm also not
opposed to moving to 2.0.
On Tue, Mar 13, 2018 at 12:17 AM, YiZhi Liu wrote:
> Kel
-1
Because of the customer pain-points mentioned by others.
I think for good customer experience,
all code in MXNet repository excluding submodules and 3rd party dependencies
should map to the same version.
Anirudh
On Mon, Mar 12, 2018 at 4:17 PM, YiZhi Liu wrote:
> Kellen, we are not talking a
I suggest the vote should call out if the change is breaking backward
compatibility or not.
I looked through the scala name changing thread and don't see justification
for a backward incompatible change.
I do agree it would be good to change the name space, but have not seen a
reason why the change
not sure I understand. How could changing a java namespace (effectively
moving the files to a different location as well as changing the package
names) be backward-compatible?
On Mon, Mar 12, 2018 at 11:02 PM Steffen Rochel
wrote:
> I suggest the vote should call out if the change is breaking b
37 matches
Mail list logo
