flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: [VOTE] Using Scala to reimplement the JobManager and TaskManager
Date Thu, 04 Sep 2014 08:30:48 GMT
+1
I think it's good to outsource functionality that is not our main
competency. Because of the origins of Flink in research we suffered a
bit from NIH in the beginning. I'm happy to see this reduced piece by
piece now.

On Thu, Sep 4, 2014 at 1:50 AM, Henry Saputra <henry.saputra@gmail.com> wrote:
> You can create patch then ask for VOTE as needed but with a lot of
> work involved I think it would be better to get some kind of agreement
> of the proposed solution before continuing.
>
> - Henry
>
> On Wed, Sep 3, 2014 at 4:25 PM, Sebastian Schelter <ssc@apache.org> wrote:
>> Hi Ufuk,
>>
>> It is up to the project where to vote upfront before working on a code
>> change or whether to do it afterwards.
>>
>> --sebastian
>>
>>
>>
>> 2014-09-03 15:55 GMT-07:00 Ufuk Celebi <uce@apache.org>:
>>
>>> Hey Daniel,
>>>
>>> I am sure that Till didn't try to set up the vote towards his desired
>>> outcome. Actually it should conform to the Apache Voting Process.
>>>
>>> Quoting from http://www.apache.org/foundation/voting.html:
>>>
>>> "Expressing Votes: +1, 0, -1, and Fractions
>>>
>>> The voting process in Apache may seem more than a little weird if you've
>>> never encountered it before. Votes are represented as numbers between -1
>>> and +1, with '-1' meaning 'no' and '+1' meaning 'yes.'
>>>
>>> [...]
>>>
>>> +0: 'I don't feel strongly about it, but I'm okay with this.'
>>> -0: 'I won't get in the way, but I'd rather we didn't do this.'
>>>
>>> [...]
>>>
>>> Vetos
>>>
>>> A code-modification proposal may be stopped dead in its tracks by a -1 vote
>>> by a qualified voter. This constitutes a veto, and it cannot be overruled
>>> nor overridden by anyone. Vetos stand until and unless withdrawn by their
>>> casters.
>>>
>>> To prevent vetos from being used capriciously, they must be accompanied by
>>> a technical justification showing why the change is bad (opens a security
>>> exposure, negatively affects performance, etc. ). A veto without a
>>> justification is invalid and has no weight."
>>>
>>> The only thing I'm not sure about is whether "upfront" votes are usual. If
>>> this was a code modification (PR or commit), the way that this is setup
>>> should definitely be OK. Maybe a mentor can help with this?
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 12:11 AM, Daniel Warneke <warneke@apache.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > sorry, but I think the way this vote is set up is already biased towards
>>> > the author’s desired outcome. Two out of the three possible options
>>> > effectively lead to the switch to Scala. Moreover, the -1 option requires
>>> > the voter to explain his/her decision, the +1 option does not.
>>> >
>>> > Best regards,
>>> >
>>> >     Daniel
>>> >
>>> >
>>> > Am 03.09.2014 22:58, schrieb Till Rohrmann:
>>> >
>>> >  In the wake of replacing the current proprietary RPC service with an
>>> Akka
>>> >> service, we have to rewrite the JobManager and TaskManager. Akka is
>>> >> implemented in Scala and offers bindings for Scala as well as Java.
>>> Since
>>> >> the implementation using Scala would probably be neater and less
>>> verbose,
>>> >> we would like to use Scala for the reimplementation. That would imply
>>> that
>>> >> Flink's runtime module would become a mixed Java and Scala project.
>>> >>
>>> >> So please vote whether Scala should be used for rewriting the JobManager
>>> >> and TaskManager or not.
>>> >>
>>> >> The vote will be open for at least 72 hours.
>>> >>
>>> >> [ ] +1 Using Scala for reimplementation
>>> >> [ ]  0 I don't feel strongly about it, but I'm okay with using Scala
>>> >> [ ] -1 Do not use Scala because...
>>> >>
>>> >>
>>> >
>>>

Mime
View raw message