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

Reply via email to