+1
On Thu, Sep 4, 2014 at 10:30 AM, Aljoscha Krettek <[email protected]> wrote: > +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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]>: > >> > >>> 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 <[email protected]> > >>> 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... > >>> >> > >>> >> > >>> > > >>> >
