After having done a lot more testing myself, and by Paul: thanks!, and based on
the feedback from Jasha, Matt and Chris, I've decided to proceed with the 0.17
release after all.
I think and hope most of the model-split merge more serious bugs have been
flushed out now. There is more we can and should improve, but that is the case
for many more areas and features. So besides the RAVE-838 issue concerning the
bad performance, mainly on the H2 database, which I will update to get fixed for
the next 0.18 release, I don't see much reason anymore to hold off the release.
For future large changes however we better discuss and decide upfront if it
should warrants a longer release cycle, and then make that explicit so everyone
can adjust and anticipate.
Please consider the trunk as of now in 'freeze' mode until the 0.17 release tag
has been set and the trunk opened for 0.18-SNAPSHOT.
Thanks,
Ate
On 11/01/2012 01:28 PM, Jasha Joachimsthal wrote:
On 1 November 2012 12:32, Franklin, Matthew B. <[email protected]> wrote:
-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Thursday, November 01, 2012 5:47 AM
To: [email protected]
Subject: Re: [DISCUSS] performance issues and the 0.17 release target
On 11/01/2012 05:50 AM, Chris Geer wrote:
On Wed, Oct 31, 2012 at 6:37 PM, Ate Douma <[email protected]> wrote:
On 11/01/2012 01:49 AM, Franklin, Matthew B. wrote:
I am +0 for the release in the current state. H2 file system
performance
is know to be an issue in general, but I don't see how a single
widget can
take that long to pull from the database.
That being said, it is still a 0.xx release, and it seems to be fine
in
MySQL.
I agree the performance issue with H2 remains worrisome.
And while I'm also +0 on doing the release, I rather see this resolved
first properly, and some more hammering out possible other wrinkles
from
the model-split merge.
Releasing right now, so shortly after the merge without proper time for
testing actually doesn't feels very proper in itself.
Keeping the monthly release momentum going though also is important,
so
I'm unsure which way to choose.
I understand the advantages of the strict monthly releases but I'd argue
the the strict schedule isn't as needed now as it was 6 months ago. Now
that we are tackling larger efforts it might be time to consider moving
to
a release-as-ready approach, provided we still do them frequently when
possible. If we want to stick with the monthly release we should put in
some guidelines on branch merges (i.e. only at the beginning of the
month)
to provide adequate time for trunk testing, or get more testing while
still
on the branch.
I agree to both options :)
I like and support a release-when-ready approach, but only when
specifically
planned as needed, only for specific cases like large branch merges. And
then
only deal with that single case, not stacking multiple major changes
within one
release cycle. And I would still stick to a regular release time-window
size,
e.g. one (or two) months. So, if a feature isn't ready within a month, we
simply
extend until the next scheduled release date, e.g. like another month
later.
Sticking to a strict release schedule (monthly or maybe bi-monthly, which
I'd
be
OK with too) remains important IMO to keep ourselves sharp and focused on
a
release early and often mindset.
Given the low(er) overhead of releases outside of the incubator, I am +1
for monthly releases as a normal cadence and release when ready for larger
changes.
I prefer monthly releases as well. It's not only about new features, but
also shipping improvements and bug fixes fast.
Personally I don't need the 0.17 release right now, nor for the
ApacheCon.
So maybe it is better to hear out what others think or need.
Should we:
a) proceed with releasing 0.17: stick to procedure and/or I need a
release
now
b) better skip one release cycle and focus on fixing and improving the
model-split merge, the H2 performance issues are cleared up and
possible
other wrinkles hammered out as well
My personal preference would be to go with option b, skip the release
(or
delay it until next week). I'm not against the release since I believe
it
still has good features and is performant running with MySQL but I don't
have a driving need to have it released.
I too am leaning towards option b) but not with only a week delay. In
that case
I prefer to delay until the next scheduled release (see above).
Please provide your feedback until say tomorrow evening, CET.
If still inconclusive by then, I'll decide myself.
Regards, Ate
Sent from a mobile device
-----Original Message-----
From: Ate Douma [[email protected]<mailto:ate@**douma.nu
<[email protected]>>]
Sent: Wednesday, October 31, 2012 08:17 PM Eastern Standard Time
To: [email protected]
Subject: Re: [DISCUSS] performance issues and the 0.17 release target
As already reported on RAVE-838, it seems H2 is the real culprit for
the
performance issue.
Even while we can/should improve on our logic to reduce the number of
times we
(re)instantiate the same persistent object during a single request,
using
MySQL
instead of H2 bring the performance back to acceptable level.
Although H2 is our default embedded database, I don't think this
problem
should
be a release blocker. Of course we must provide proper release notes
informing
the community about this issue with H2, but as I expect/hope nobody
uses
H2 for
real, this shouldn't be a show stopper for anyone.
So, I propose to proceed with the 0.17 release, meaning going for
option
a)
below. Because it already is rather late here (Europe), I will start
on
this
tomorrow morning my time, assuming lazy consensus.
If anyone thinks different, please chime in.
Regards, Ate
On 10/31/2012 06:11 PM, Chris Geer wrote:
On Wed, Oct 31, 2012 at 10:02 AM, Ate Douma <[email protected]> wrote:
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).
e) Back out the model-split branch merge, fix any issues on the
branch
then
remerge in the future.
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
I would vote for a or b, but those depend on other input of impact
from
other users. Based on input so far, c seems risky to me because
there is
no
way to know if the majority of people will have my performance or
Ate's.
Under normal circumstances, d would be a decent choice but with
ApacheCON
EU coming up I'm not sure it's good now. Choice e isn't my first
choice
but
it's technically a choice and can be done if people think it's the
best
option.
Chris
