hi guys How about adding a bin/build_release.sh (http://build_release.sh) script in this 0.9.2-incubating release?
Since some guys asked the question about building storm release package more than once in the mail list. -- Best Regards! 肖康(Kang Xiao,<[email protected] (mailto:[email protected])>) Distributed Software Engineer 在 2014年3月25日 星期二，1:38，Suresh Srinivas 写道： > 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] > (mailto:[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] > > > (mailto:[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] > > > > (mailto:[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] > > > > (mailto:[email protected])> > > > > wrote: > > > > > > > > > Never mind... just found it. > > > > > > > > > > > On Mar 20, 2014, at 5:09 PM, P. Taylor Goetz <[email protected] > > > > > > (mailto:[email protected])> > > wrote: > > > > > > > > > > > > Derek do you have an idea for a fix? > > > > > > > > > > > > On Mar 20, 2014, at 3:43 PM, Derek Dagit <[email protected] > > > > > > (mailto:[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. > > >
