Hi all,

As you all might have noticed, after the model-split branch merge, I've encountered a major performance degrading, at least in my standard Rave trunk build environment. More details about this in RAVE-838 where Chris and Matt also have chimed in on the discussion so far.

The question I need to raise is: how should we deal with this while the 0.17 release target is or was planned for today?

IMO we have about 4 options to choose from:

a) The performance issues turn out to be either easily fixable or else not reproducible (enough) for this to be a show stopper: 0.17 release can continue as planned, maybe with only a slight (1 day max) delay to properly verify this.

b) The performance issues are serious enough to warrant fixing first, but can be done on short notice, delaying the 0.17 release but no more than 2 days (e.g. Friday the latest)

c) The performance issues are serious and cannot be fixed properly before end of the week. However it is important* to have the 0.17 release done anyway, in which case the community needs to be informed that this release isn't really usable other than for development purposes. For example, we could postfix the release version like 0.17-dev.
* Why might a 0.17 release be desired, even with serious performance issues?
- Because it allows completing and verifying *other* 0.17 features, even if only in a development environment - because it is desirable to have a new release ready before ApacheCon EU, for the community as well as for Rave specific presentations, e.g. for Matt's and/or my own presentation. However: I'm also considering temporarily downgrading the current Rave content services sandbox to use Rave 0.16 instead, so *for me* this might not be important, even if less ideal.

d) The performance issues are serious and doing the 0.17 release *now* isn't that critical, so simply skip the release this month and re-schedule 0.17 release for next month (no need to 'drop' the 0.17 version IMO).

As I just commented on RAVE-838, I'll do some more testing (with MySQL instead of H2 database) later this evening.

Besides that, I'd appreciate if others also can verify and report their own performance experience with the current trunk, and provide some feedback and opinion on the options I gave above.

Thanks, Ate

Reply via email to