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
