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... > >> > >> > > >
