On Fri, Mar 21, 2014 at 10:14 PM, P. Taylor Goetz <[email protected]> wrote:
> Agreed. > > I think now that our committer base is growing, I think we are better > positioned to support that model. > Lazy consensus is a powerful mechanism. Committers are chosen because of their quality contributions to the project. Lazy consensus ensures that the project can still move forward even when the project goes through dry spells where committer activity is low. There is no requirement to make it part of the project's commit policy, but most communities implement it in some form due to its unique ability to both start conversation around changes and ensure the project does not completely stall if most committers are busy. > > -Taylor > > > On Mar 21, 2014, at 9:58 PM, Nathan Marz <[email protected]> wrote: > > > > 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 >
