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
