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