+1 for merging. -Taylor
> On Mar 30, 2016, at 4:53 PM, Bobby Evans <[email protected]> wrote: > > I think STORM-822 is ready, unless someone has an objection. It would be > nice to do some performance tests with it, but that can be in a follow on > JIRA, and if we see issues we can put it in a point release. > - Bobby > > On Tuesday, March 29, 2016 4:12 PM, P. Taylor Goetz <[email protected]> > wrote: > > > Update: > > I added STORM-1632 back to the 1.0 release epic in JIRA since Roshan is > working on a fix. Once that fix is accepted we can proceed with a release. > > Aside from that STORM-1491, still has some open issues, but they are for > documentation which we should be able to handle in parallel with the release > (but should be addressed before we ANNOUNCE). > > STORM-822 is getting close, but I’m hesitant to delay the release for it. If > it makes it, great. If not, we could certainly include it in a subsequent > release (1.0.1, 1.1, etc.). > > -Taylor > > >> On Mar 29, 2016, at 3:16 PM, Kyle Nusbaum <[email protected]> >> wrote: >> >> STORM-1595 is closed now. I wasn't able to reproduce it again. >> -- Kyle >> >> On Monday, March 28, 2016 8:28 PM, Jungtaek Lim <[email protected]> >> wrote: >> >> >> Thanks Bobby and Taylor, >> >> I intended to initiate discussion about handling holding issues (STORM-1560 >> <https://issues.apache.org/jira/browse/STORM-1560> and STORM-1595 >> <https://issues.apache.org/jira/browse/STORM-1595>) since those issues are >> no progress on it and cannot reproduce for now but can hold releasing 1.0.0. >> Since STORM-1560 is moved out of 1.0.0, we only left STORM-1595 >> <https://issues.apache.org/jira/browse/STORM-1595>, which is marked as >> 'Major'. >> Would we like to move this out of 1.0.0, too? >> >> Regarding STORM-1632 <https://issues.apache.org/jira/browse/STORM-1632>, >> I'm also OK to choose either option you provided. >> Though we already moved issue out of 1.0.0, conversation becomes getting >> longer because of instability of benchmark numbers. >> (I would like to lend a hand to Bobby since Bobby showed amazing details >> when evaluating performance.) >> But one thing we seems have consensus is that event logger is a feature >> which could be OK to disable by default. (UI should be reflected) >> I asked Harsha who filed the issue to see needs or use cases of event >> logger, and Harsha said he guess it would be likely to be used with dev. >> cluster and rarely used on production. >> >> Seems like there's some progress to resolve on issue today, so I'd like to >> follow. >> >> Thanks, >> Jungtaek Lim (HeartSaVioR) >> >> 2016년 3월 29일 (화) 오전 6:15, P. Taylor Goetz <[email protected]>님이 작성: >> >>> FYI, I pulled STORM-1560 from the 1.0 release epic, and marked all issues >>> with active pull requests as “in progress”. >>> >>> -Taylor >>> >>>> On Mar 28, 2016, at 4:18 PM, P. Taylor Goetz <[email protected]> wrote: >>>> >>>> I would like to be able to initiate a release VOTE this week. We are >>> very, very close. >>>> >>>> Pretty much everything under STORM-1491 has been addressed, and should >>> be able to be merged soon. >>>> >>>> The two outliers are: >>>> >>>> STORM-1560 (Reported by me. I’m ready to close this, since I’ve not been >>> able to reproduce it reliably.) >>>> STORM-1595 (Reported by Kyle. Still waiting for information about how to >>> reproduce this.) >>>> >>>> Aside from that is the debate over disabling the event logger by default >>> (STORM-1632). Yes, there is a performance hit, especially in a >>> single-node/single-worker configuration. In a multi-node/multi-worker >>> configuration, that hit is significantly reduced. >>>> >>>> For STORM-1632 I see two options: >>>> >>>> 1. Ship with event logging enabled by default so the UI doesn’t appear >>> broken by default. >>>> 2. Update the UI so the user knows when feature is disabled, and give >>> clear instructions on how to enable it. Ship with event logging disabled by >>> default. >>>> >>>> I support either option. We could even ship 1.0 with option #1, and >>> follow with a 1.0.1 release with option 2 implemented. We could even >>> release 1.0 with a documented “known issue” that for best performance, >>> users should disable event logging in production. >>>> >>>> -Taylor >>>> >>>> >>>> >>>>> On Mar 28, 2016, at 3:50 PM, Bobby Evans <[email protected]> >>> wrote: >>>>> >>>>> I would be happy to see a 1.0 release sooner rather then later. If >>> there are some issues that are blocking it being released that you don't >>> feel should be blocking it I am happy to join in that conversation. >>>>> - Bobby >>>>> >>>>> On Friday, March 25, 2016 11:55 PM, Jungtaek Lim <[email protected]> >>> wrote: >>>>> >>>>> >>>>> Hi devs, >>>>> >>>>> I guess it's been two months after creating issue for releasing 1.0.0 ( >>>>> STORM-1491 <https://issues.apache.org/jira/browse/STORM-1491>), which I >>>>> expected it's in progress of releasing so it can be resolved in several >>>>> weeks. >>>>> >>>>> Porting works for preparing 2.0.0 are in progress simultaneously. >>>>> I think two track strategy is great, but publishing releases >>> continuously >>>>> can make community more active and prevents specific release having >>>>> too-many changes. 1.0.0 is one of the example, and I suspect its reason >>> to >>>>> drag releasing 0.10.0 (including beta) too long. >>>>> >>>>> I'd like to propose that we have some moments to concentrate on >>> releasing >>>>> 1.0.0, and back to work. >>>>> Concentration includes discussion about lowering issues' priority, >>>>> excluding issues from epic (which means out of 1.0.0), assigning issues >>>>> which are remaining but not resolved yet. >>>>> >>>>> What do you think? >>>>> >>>>> Thanks, >>>>> Jungtaek Lim (HeartSaVioR) >>>>> >>>>> >>>> >>> >>> >> > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
