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)
>>>>
>>>>
>>>
>>
>>
>
