IMO it should be two +1 votes by committers (separate from whoever submitted the patch) and no -1 votes. This is what we were using before going into Apache, and I think it's still the right model to use. I think it's a relatively safe voting process that should prevent bad changes from getting in, but it's not overly restrictive.
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 > -- Twitter: @nathanmarz http://nathanmarz.com
