I will send results on this soon
On 2018/03/13 16:23:37, Chris Olivier wrote:
> How many people do we estimate are currently using the Scala interface?
> Probably the actual blast radius should be considered. If it is very
> small, then we can probably have more "wiggle
If you were to have two implementations you would want to annotate the old one
as deprecated immediately. I don't think you would want to commit to supporting
it for more than a couple of months. How many users of the Scala MXNet
interface are there in any case? And do they really view the
The namespace change is the first thing that's done for most projects that
come to apache incubation
How many production deployments of MXNet Scala API are out there --- 3 ? 2
? 1.7643 ?
I would think its barely a handful of them.
Agree with Christopher Barber that MXNEt jumped the gun with
I'm not taking a side here, but just please consider that if you have two
separate implementations for awhile, the newer one will start to diverge
and over time, it will become harder and harder for the user to port his
code. You may find yourself supporting the old code for much longer than
you
How many people do we estimate are currently using the Scala interface?
Probably the actual blast radius should be considered. If it is very
small, then we can probably have more "wiggle room", so to speak.
On Tue, Mar 13, 2018 at 9:00 AM, Chernov, Anton wrote:
> I see (2)
that might be the last thing we want to do, i.e. keeping some code just for
the namespace change,
I am open to have such a PR with the assumption that
1. changing namespace is scheduled to be finished at 1.x versions
(alternatives might be when we graduate as TLP)
2. breaking backward
I see (2) being the appropriate way to go. Scala code is copied to a new
namespace and all the old code gets a deprecation mark which means it's only
supported for backwards compatibility and will not be modified unless there
will be an urgent fix.
On 13.03.18, 16:52, "kellen sunderland"
Maintaining backwards compatibility never results in the prettiest code,
but it seems pretty desirable here. There are relatively few files here,
so I agree there's some risk but I don't think it would take too much
time. Feel free to suggest alternatives Christopher.
On Tue, Mar 13, 2018 at
That sounds like a lot of work and it would be easy to get wrong if it is even
feasible.
On 3/13/18, 11:51 AM, "kellen sunderland" wrote:
I don't know about aliasing a namespace in Scala, but I wonder how hard it
would be to either (1) provide a fascade
re Chris: I do not have any good idea about this.
On Tue, Mar 13, 2018 at 8:13 AM, Chris Olivier
wrote:
> is it possible to somehow alias a namespace in scala
> in order to maintain backwards compatibility?
>
> On Tue, Mar 13, 2018 at 7:21 AM Nan Zhu
is it possible to somehow alias a namespace in scala
in order to maintain backwards compatibility?
On Tue, Mar 13, 2018 at 7:21 AM Nan Zhu wrote:
> +1
>
> and additional suggestion is do it ASAP
>
> On Mon, Mar 12, 2018 at 11:21 PM, Chris Olivier
+1
and additional suggestion is do it ASAP
On Mon, Mar 12, 2018 at 11:21 PM, Chris Olivier
wrote:
> 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
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
+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
>
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
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
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
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
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,
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
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
+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
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
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
24 matches
Mail list logo