[sakai2-tcc] Maintenance Branch Merge Policy: Delegated Access Patches SAK-22079

[Matthew Jones]

I've also discussed it with Bryan and am fine with the change.

The merge policy does say that two announcements should be sent out, which
there were. No vote is required.

If there's no objection then this will be merged by the next beta tag which
would be released in ~3 weeks.

On Mon, Apr 23, 2012 at 6:58 PM, Steve Swinsburg
<steve.swinsburg at gmail.com>wrote:

> I'm fine with this. According to Bryan it doesn't impact anything unless
> explicitly enabled.
>
> More info here:
> https://confluence.sakaiproject.org/display/DAC/Delegated+Access+Tool
>
> cheers,
> Steve
>
>
>
> On 19/04/2012, at 3:41 AM, Bryan Holladay wrote:
>
> > TCC et al,
> >
> > I am requesting a few small patches to be included in to the Sakai
> > 2.9.x maintenance branch so that the Delegated Access 1.0 release will
> > be compatible with the 2.9.x branch of Sakai.  I feel this is
> > important for the adoption of this tool because of how far away the
> > 2.10.0 release for Sakai is.  There are no API changes, no DB changes,
> > and only tool functionality changes if the delegated access tool is
> > being used.
> >
> > I have created a jira (SAK-22079) for a Sakai 2.9.x maintenance branch
> > merge.  The patches are linked in the description.  Each patch is a
> > minimal modification that uses a user's session, sakai.props and sakai
> > events to communicate with the Delegated Access tool and doesn't
> > effect the tools if the delegated access tool isn't included in the
> > build or being used.
> >
> > I am willing to do all the merging and QA testing required for these
> patches.
> >
> > Here are my comments on the qualifications listed in
> >
> https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy
> >
> >
> >> The change is narrow in scope (modest changes to a single project)
> >
> > Each project (kernel, portal, site-manage) do not depend on each other
> > and creates no dependencies to the Delegated Access tool. They use
> > Session variables, sakai.props and event triggers to communicate. If
> > there are no session variables for delegated access, the behavior
> > stays the same in each tool
> >
> >> The change has been reviewed and approved by tool lead for the
> maintenance branch
> >
> > This email is requesting the patch reviewal.
> >
> >> The change does not require database changes
> >
> > No db changes required
> >
> >> The change has been running in production for one month minimum
> >
> > Columbia has been running these patches in production for over a month
> (2.8.x)
> >
> >> Changes that could impact internationalization negatively must be
> tested in two languages that are not variants of the same country.
> >
> > No internationalizations changes in these patches
> >
> >> The change is non-disruptive to the user experience ( I.e. changes that
> don't require user retraining and are unlikely to break existing
> customizations).
> >
> > Unless the institution enables Delegated Access, there will be no
> > disruptions to the user experience.
> >
> >> Exceptions to this rule may be made if the change is configurable and
> is disabled by default.
> >
> > The user facing changes are configurable and off by default (site-manage)
> >
> >> Prior to merging, the change must be tested with the target maintenance
> branch, by the requesting institution, using a documented test plan.
> >
> > I will spearhead the testing (bryan)
> >
> >
> >
> > Thanks,
> > Bryan
> > _______________________________________________
> > sakai2-tcc mailing list
> > sakai2-tcc at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20120423/b9048ab0/attachment.html