[cle-release-team] SAK-22978

[Matthew Jones]

Okay, since you actually have to add the bean and implement the provider,
I'm convinced there's no need for the property. Noah assured me there's
best practice suggestions in the comments to help contrib tools avoid the
same performance problems that happened here.

One thing I was looking at for the release was conversion scripts. I notice
that this script wasn't in trunk, but was happy Sam was adding conversions
to it in the branch.
http://source.sakaiproject.org/viewsvn/reference/branches/sakai-2.9.x/docs/conversion/sakai_2_9_0-2_9_1_oracle_conversion.sql

We should probably copy it into the trunk and verify all conversions are
in, I forget the process in the past.

I ran this filter and only 1 issue accounted for is in there, but only
tracks if the checkbox is marked AND the fix version is correct.

(project = SAK OR project=BLTI OR project=KNL or project=LSNBLDR OR
project=MSND OR project=MSGCNTR OR project=POLL OR project=PRFL OR
project=RES OR project=SAM OR project=SRCH OR project=SHORTURL OR
project=STAT) AND fixVersion = "2.9.1-rc01" and "Conversion Script
Required" = Yes ORDER BY status DESC, priority DESC

One of the issues in the SVN log is
https://jira.sakaiproject.org/browse/SAK-22946

But this doesn't have a conversion . . . This issue is actually SAK-22496
and didn't have the checkbox checked. I've checked the box, commented to
check it in the future and edited the svn commit message with the right SAK.



On Wed, Jan 23, 2013 at 11:07 AM, Jean-Francois Leveque <
jean-francois.leveque at upmc.fr> wrote:

> AZ gets a +1 on this. If all is fine, why keep a property for switching
> it off?
>
> J-F
>
> On 23/01/2013 16:58, Neal Caidin wrote:
> > Thanks for cc'ing in the CLE release team.
> >
> > For those who need a short summary, the debate is whether now that this
> > has been completed:
> >
> > https://jira.sakaiproject.org/browse/SAK-22978 - Performance issue with
> > group member items in gradebook
> >
> >
> > do we still need a property to turn off the group membership lookup in
> > the gradebook? :
> >
> > https://jira.sakaiproject.org/browse/SAK-23004
> >
> >
> > Details in thread below.
> >
> > Cheers,
> > Neal
> >
> >
> >
> > On Jan 23, 2013, at 8:25 AM, Aaron Zeckoski <azeckoski at unicon.net
> > <mailto:azeckoski at unicon.net>> wrote:
> >
> >> I don't think we should have random properties to turn off things that
> >> might be an issue but are currently not. Considering the other areas
> >> of Sakai which are much worse performance issues than this it seems
> >> like we are stuck on this topic. I suggest that unless there are
> >> current performance problems with this specific feature that we drop
> >> this and move on to other more pressing issues for this release.
> >>
> >> -AZ
> >>
> >>
> >> On Wed, Jan 23, 2013 at 8:07 AM, Noah Botimer <nbotimer at unicon.net
> >> <mailto:nbotimer at unicon.net>> wrote:
> >>> I agree, but I think we already have a way to manage badly behaved
> tools.
> >>>
> >>> My feeling is that we should be most concerned with the core release
> >>> here.
> >>> I'd hesitate to put in a global kill switch to protect specific core
> >>> functionality from a theoretical, defective add-on. I'm quite sure
> >>> that no
> >>> one has implemented a contrib provider yet.
> >>>
> >>> There is already an amount of effort and familiarity required to run
> any
> >>> given contrib tool, so it doesn't particularly bother me to use the
> >>> mechanism in place: just don't register the troublesome provider. I
> think
> >>> that keeps the focus, responsibility, and fix closest to the potential
> >>> issue. Now that we're pretty confident in the general, core
> >>> performance, I
> >>> think this is the way to go.
> >>>
> >>> I think this, along with many other things, is up for consideration if
> we
> >>> get to the point where we have cluster-wide, runtime configuration.
> >>>
> >>> For the hacky amongst you, it's possible to manage an emergency at
> >>> runtime
> >>> to avoid a restart. Drop a JSP somewhere, get the
> >>> GradebookExternalAssessmentService bean, and unregister the flaky
> >>> provider.
> >>> Then you could prepare for a scheduled restart in relative calm.
> >>>
> >>> Thanks,
> >>> -Noah
> >>>
> >>>
> >>> On 01/22/2013 08:12 PM, Matthew Jones wrote:
> >>>
> >>> I think the only thing that concerned me about *removing* the property
> >>> rather than switching the default, is that if some other tool went and
> >>> implemented the isAssignmentGrouped in their provider that we didn't
> know
> >>> about yet, and had bad performance (say a contrib tool or something)
> >>> there
> >>> would be no way to turn off this feature. Say if mneme or something
> >>> did it,
> >>> just as an example.
> >>>
> >>> I want to have seen the end of this, but it just feels like we might
> not
> >>> have seen the end . . . ;(
> >>>
> >>>
> >>> On Sun, Jan 20, 2013 at 2:27 PM, Neal Caidin
> >>> <nealcaidin at sakaifoundation.org
> >>> <mailto:nealcaidin at sakaifoundation.org>> wrote:
> >>>>
> >>>> Hi Noah,
> >>>>
> >>>> Yes, those properties are indeed a mixed blessing. I guess if nobody
> has
> >>>> any objections then we should simply inform the CLE release team?
> >>>>
> >>>> Neal
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20130123/6aae947c/attachment-0006.html