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. > > 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. > > 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 >>> >>> >> >
