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
