Unless there are any objections, I intend to cut a release candidate once STORM-1632, STORM-1668, and STORM-1669 have been merged (pull requests are still in the 24 hr. review window).
If you have any concerns, please let me know. -Taylor > On Mar 30, 2016, at 4:59 PM, P. Taylor Goetz <[email protected]> wrote: > > +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
