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