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