Taylor, I am not very clear on "Lazy consensus +2". By this definition code can committed with no +1 from a committer, right?
You may want to look at Hadoop bylaws - https://hadoop.apache.org/bylaws.html The code commits in Hadoop are consensus approval with minimum +1 from an active committer and no veto. This has worked well in my experience. It may be a good idea to also adapt minimum 3 +1s from active committers for merging feature branches. On Fri, Mar 21, 2014 at 6:22 PM, P. Taylor Goetz <[email protected]> wrote: > That brings up a good point that probably deserves a separate thread. > > We should establish by-laws soon. Specifically a commit/merge policy. > > For code changes, I've been operating under a "lazy consensus +2" model: 2 > committer +1 votes and no vetoes (-1). If a committer submits the patch, > that's an implicit +1. Unless it's a somewhat urgent fix, I've been waiting > for 3 binding votes and no vetoes. > > That's kind of a middle ground between the traditional code modification > rule and lazy consensus [1]. > > When wearing my "release manager" hat, I've also interpreted "code change" > to mean "anything that alters the behavior of the software we produce." In > terms of the build/packaging I've been a little looser. For large changes > (e.g. The switch to maven), I've waited for 3 binding votes. For some > changes I've committed directly -- I don't think we need to have a 3-day > vote on updating the CHANGELOG, for example. > > Anyway, it's something to think about. Sorry for hijacking the thread. > > +1 (again ;) ) > > Taylor > > [1] https://www.apache.org/foundation/voting.html > > > On Mar 21, 2014, at 7:48 PM, Nathan Marz <[email protected]> wrote: > > > > Let's get https://issues.apache.org/jira/browse/STORM-262 in there. Just > > one more vote needed by a committer. > > > > > >> On Fri, Mar 21, 2014 at 3:21 PM, Patrick Lucas <[email protected]> wrote: > >> > >> A fix STORM-120 would be greatly appreciated. It's making it impossible > to > >> increase tasks/executors > 1 when there is a downstream shuffle > grouping. > >> > >> I'm not sure why there haven't been more reports of problems with it. > Two > >> possibilities I can think of are that we are using exclusively shell > >> components--perhaps there's a root-cause bug in those component > >> classes--and > >> that we are dealing with a high volume stream of large tuples. > (thousands / > >> sec, KB in size) > >> > >> > >> On Thu, Mar 20, 2014 at 2:14 PM, P. Taylor Goetz <[email protected]> > >> wrote: > >> > >>> Never mind... just found it. > >>> > >>>> On Mar 20, 2014, at 5:09 PM, P. Taylor Goetz <[email protected]> > wrote: > >>>> > >>>> Derek do you have an idea for a fix? > >>>> > >>>> On Mar 20, 2014, at 3:43 PM, Derek Dagit <[email protected]> > wrote: > >>>> > >>>>>> As I said above, this fix is the most important in my opinion. > >>>>>> STORM-259 (Random#nextInt) is new to me -- can't say whether it's as > >>>>>> important as STORM-187 or not. > >>>>> > >>>>> Yeah, we found it recently, and I created it this morning after > >> reading > >>> Taylor's mail. > >>>>> > >>>>> STORM-187 can be a problem with fewer than 30 retries (likelihood > >>> depends on configuration), but we will hit STORM-259 when retries > exceeds > >>> 30. > >>>>> > >>>>> -- > >>>>> Derek > >>>>> > >>>>>> On 3/20/14, 14:18, Michael G. Noll wrote: > >>>>>> On my side the most important change is, as you point out, > STORM-187. > >>>>>> The primary reason is like Adam Lewis is pointing out because it's a > >>>>>> stability problem. The secondary aspect is that this issue taints > >> the > >>>>>> new Netty backend, and at least IMHO the faster Storm could > >> confidently > >>>>>> bury ZeroMQ the better. :-) > >>>>>> > >>>>>> As I said above, this fix is the most important in my opinion. > >>>>>> STORM-259 (Random#nextInt) is new to me -- can't say whether it's as > >>>>>> important as STORM-187 or not. > >>>>>> > >>>>>> Switching to my non-essential wishlist I'd also +1 STORM-252 > (Upgrade > >>>>>> Curator and thus ZooKeeper to 3.4.5). We have been running ZK 3.4.5 > >>>>>> anyway for a couple of reasons, and it would be nice to have > official > >>>>>> Storm support for the latest ZK version (ok, the recently released > ZK > >>>>>> 3.4.6 is actually the latest but hey). Although I don't know how > >>>>>> confident we are that the code in STORM-252 actually works, i.e. > >>> whether > >>>>>> integrating STORM-252 into 0.9.2 on such short notice would be > >> jumping > >>>>>> the gun or a safe move. > >>>>>> > >>>>>> Btw, in terms of Storm/Kafka integration Kafka is in the same boat: > >>>>>> it's built against ZK 3.3.x, and LinkedIn recommends the use of ZK > >>> 3.3.4 > >>>>>> in the docs. There's an open ticket KAFKA-854 [1] that's basically > >> the > >>>>>> equivalent of STORM-252, but I'm not sure how actively the Kafka > team > >>> is > >>>>>> working on that. > >>>>>> > >>>>>> Best, > >>>>>> Michael > >>>>>> > >>>>>> [1] https://issues.apache.org/jira/browse/KAFKA-854 > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 03/20/2014 02:33 AM, P. Taylor Goetz wrote: > >>>>>>> I'd like to get this discussion started, largely because the > >>> "negative timeout" bug (STORM-187) really bothers me. I've not seen it > in > >>> the wild, but I've heard of a few cases where it was enough to hinder > >>> upgrading. > >>>>>>> > >>>>>>> HEAD looks good to me at the moment, with the major difference > being > >>> the zookeeper update and the patch mentioned above. > >>>>>>> > >>>>>>> Any thoughts on other PRs or patches to include? > >>>>>>> > >>>>>>> -Taylor > >>>>>> > >>>> > >>> > >>> > >> > >> > >> -- > >> Patrick Lucas > >> > > > > > > > > -- > > Twitter: @nathanmarz > > http://nathanmarz.com > -- http://hortonworks.com/download/ -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
