[Building Sakai] [Management] MT deprecation recommendations for 2.7

Anthony Whyte arwhyte at umich.edu
Wed Mar 17 14:55:13 PDT 2010 

Yes, I sidestepped both JCR as well as the static cover deprecations recommendations in my email of last Sunday, choosing instead to focus solely on 2.7 tool deprecations in an effort to secure at least lazy consensus on how I planned to handle deprecations in the next QA tag.

JCR
Despite the experimental nature of JCR I recommend we follow the same approach as we do for tool deprecations: deprecate in kernel-1.1 and remove in kernel-1.2 (moving JCR to contrib).  This should provide sufficient time for anyone using the JCR service to adjust their build practices to compensate for it's eventual removal from the kernel.  We should announce this decision with a deprecation alert (I plan to draft these when I return to the US) and provide one or more reminders of JCR's impending removal during 2010, early 2011.

COVERS
You've no doubt seen the objections raised regarding deprecating static covers in the kernel and elsewhere.  While I am not persuaded by the claims that static cover removal truly raises barriers to writing Sakai tools--is it really all that challenging to add a service injection setter method that relies on a bit of XML residing in a Spring bean configuration file?--I am sensitive to the assertion that static cover removal imposes costs on those maintaining local code that make use of the covers.  Indeed, for an example of the refactoring involved in removing static covers in favor of service injection see http://jira.sakaiproject.org/browse/SAK-12077.  The work, while by no means onerous or difficult, is nevertheless non-trivial.

Moreover, the kernel team is currently split on this issue in so far as static cover removal is concerned--a difference of opinion that raises something of a blocker to the removal proposal, although it should be recalled that static cover removal as proposed by David Horwitz would not commence for some time.

COMPROMISE PROPOSAL
I'd like to see static covers eventually removed (so +1) but recognize that the current crowd wisdom appears to consider this desire, well, unwise.  Still, I'd like to suggest a compromise proposal, one that permits the removal of a static cover whenever it impedes the implementation of unit tests written in support of a bug fix.  Extension of 2.x unit test coverage is work that meets a long standing yet largely unrealized goal of the Sakai Community.  Suspending such work because one finds a static cover in the way appears to me unwise.

Cheers,

Anth


On Mar 17, 2010, at 8:19 PM, Clay Fenlason wrote:

> Anthony:
> 
> Sorry that your earlier note slipped past me, and that I then retrod
> much of the same ground.
> 
> What you've proposed sounds consistent to me with our informal
> deprecation policy and the comments others have made on list recently.
> 
> With perhaps one exception. It's not clear to me what the consensus is
> on the JCR service. Stephen questioned its removal (presumably to
> contrib) given that at least one known tool makes use of it. Ian then
> confirmed that Cambridge also has it running in production. Ian has
> said it's ok with him to move it into contrib, but I take that in the
> same spirit in which it's ok with Noah if OSP tools go into contrib -
> they're both comfortable making the code do what they want it to, and
> we need to also be concerned with others who can't adapt as quickly.
> 
> But given the range of options available (eg. leave it in trunk or a
> source checkout, but not a release binary, etc.) it's not clear to me
> what the right balance is to strike with the JCR Service, apart from
> the fact that it seems best not to move it to contrib straight away.
> I'm not proposing a particular solution, I just want to be clear on
> where consensus opinion has come down, or at least get something
> spelled out that makes people realize we need to hash it out some
> more.
> 
> ~Clay
> 
> On Sun, Mar 14, 2010 at 7:40 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>> In an earlier email I provided clarification regarding the MT's list of 2.7
>> deprecation recommendations and I have seen no compelling arguments that
>> suggest we should undertake a different course of action with respect to
>> mailtool, presentation, reports, warehouse and blog.   So I plan to do the
>> following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22
>> March 2010.
>> Deprecated as of 2.6.0, remove from 2.7.0
>> 1. Mailtool: remove the project from svn .externals and eliminate it from
>> the tag.  When convenient we migrate mailtool to contrib and eliminate it
>> from trunk/2.7.x.
>> 2. Presentation: remove the project from svn .externals and eliminate it
>> from the tag.  When convenient we migrate presentation to contrib and
>> eliminate it from trunk/2.7.x.
>> Unsupported trunk/2.7.x code
>> 1. Stealth reports
>> 2. Stealth warehouse
>> 3. Stealth blog
>> When I get back to the US I will start work on the 2.7.0 install guide and
>> release notes.  The release notes will list blog, reports and warehouse as
>> deprecrated and targeted for removal in the next Sakai 2.x minor release
>> (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override;
>> an option that in my view does not impose an undue burden on school's that
>> want/need to run blog, reports and warehouse in 2.7.
>> If one or more institutions wish to step forward and provide active support
>> for either reports (e.g., IU for instance), warehouse or blog we should
>> consider unstealthing the tool either for 2.7.0 (if immediate support is
>> available) or perhaps for 2.7.1 (allowing the team some ramp up time).
>>  Schools can take over the tool by forming a conventional team (e.g. like
>> the msgcntr or samigo teams) or contribute one or more resources to the
>> maintenance team that can focus on it (as has occurred recently when I
>> invited David Roldan Martinez to join the maintenance team to work on i18n
>> issues).
>> We should be firm when it comes to unsupported/abandoned tool code in core
>> Sakai: the tool gets marked as deprecated and stealthed in sakai.properties
>> for the upcoming release.  A community alert regarding the change in status
>> should be issued and institutions with a stake in a deprecated tool should
>> be invited to step forward to help maintain it.  If no one steps forward the
>> tool is targeted for removal in the next minor release.
>> We generate releases for the benefit of the entire community not single
>> institutions.  Given this we should be wary of permitting
>> unsupported/abandoned code to exist in production releases because one
>> institution or another may be inconvenienced by either stealthing or
>> removal.
>> If anyone objects to the plan outlined above regarding the next QA tag
>> please reply on list.
>> Cheers,
>> Anth
>> 
>> Begin forwarded message:
>> 
>> From: Anthony Whyte <arwhyte at umich.edu>
>> Date: March 13, 2010 1:50:23 AM GMT+02:00
>> To: Clay Fenlason <clay.fenlason at et.gatech.edu>
>> Cc: "May, Megan Marie" <mmmay at indiana.edu>,
>> "management at collab.sakaiproject.org" <management at collab.sakaiproject.org>,
>> "production at collab.sakaiproject.org" <production at collab.sakaiproject.org>,
>> "sakai-dev at collab.sakaiproject.org Developers"
>> <sakai-dev at collab.sakaiproject.org>
>> Subject: Re: [Building Sakai] [Management] FW: [Deploying Sakai] MT
>> deprecation recommendations for 2.7 (fwd)
>> 
>> Regarding Mailtool and Presentation:  both tools were listed as deprecated
>> and removed in the 2.6 release notes originally compiled by Peter Knoop in
>> 2008-09.  Neither were actually removed but were instead stealthed.  From
>> the reference below it appears that both tools should have been excluded
>> from the 2.6 build.  Removing these tools (at a minimum) from the default
>> 2.7.0 build profile simply follows what I understand is our existing
>> tool/services deprecation policy that targets the elimination of
>> tool/service capabilities in the release following the stealthing or removal
>> from the build of existing capabilities.  From that standpoint the
>> recommendation is more of a reminder.
>> 
>> See: http://confluence.sakaiproject.org/display/REL/Sakai+2.6
>> 
>> I am, however, proceeding from the standpoint that cutting things out
>> 
>> of 2.7 at this point would call for rather exceptional circumstances,
>> 
>> and I'm not sure any of these items call for such action. We need to
>> 
>> talk this through. I am going to use these cases to try to draft a
>> 
>> deprecation policy - with help, and I'll work to make a start this
>> 
>> weekend -
>> 
>> 
>> Reports & Warehouse: in the case of reports and warehouse deprecation the
>> recommendation arises from the recent discovery that neither tool is
>> supported actively by the OSP team.  Recommending that the tools be removed
>> from the default build profile but not from the svn .externals file (e.g.
>> they will remain part of the download) commences the process of deprecation
>> according to our existing process.  If we can locate individuals or a team
>> that is willing to support these projects then we can terminate the
>> deprecation process.  But we should not hesitate to commence the wind down
>> of capabilities that are either obsolete or unsupported.
>> 
>> Blog: In my opinion we should initiate the same deprecation process with
>> Blog given that it too is currently not actively supported.  The
>> recommendation below calls for outright removal -- perhaps this is over
>> strong but at a minimum I think we should stealth it for 2.7.0.
>> 
>> Profile: has been superseded in the 2.7.x by Profile2.  It remains in the
>> release because both Profile2 and Roster are each dependent on the profile
>> "classic" api.  With a bit of refactoring in these projects profile classic
>> (currently an indie release) could be put out to pasture.
>> 
>> JCR: Ian has already commented on JCR.
>> 
>> Kernel utils: the recommendation here is simply to start deprecating home
>> grown utils in favor of well-known and accepted open-source alternatives.
>> 
>> Static covers: some people love them but people who think unit tests hate
>> them.  Ian Boston is one among many who has long advocated discontinuing
>> their use.  Beginning the deprecation process is long overdue.  See
>> http://blog.tfd.co.uk/2007/09/05/unit-testing-strategies/
>> 
>> On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:
>> 
>> Thanks for the clarification, Noah.
>> 
>> It still, however, leaves us in a situation where we've heard from two
>> institutions that use Reports in production (IU and RI), and there may
>> be others we haven't heard from. I think we need to assume so, nor can
>> we assume that all such institutions are able to work with the source.
>> 
>> ~Clay
>> 
>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <botimer at umich.edu> wrote:
>> 
>> I made a change to address a static code review finding. Things were broken
>> 
>> afterwards. I reverted that change and do not plan to try again to address
>> 
>> the static analysis concern.
>> 
>> I am, for my part, done with reports for 2.7 and concur with the
>> 
>> recommendation to move to contrib. To speak plainly, I see it as a
>> 
>> functional trap that suggests desirable functionality but leads to much
>> 
>> wandering and confusion. Michigan does not plan to support the tool. Others
>> 
>> might, but I still recommend it live in contrib. I thank John for his honest
>> 
>> appraisal.
>> 
>> The functional and technical investment requirements for usage warrant, to
>> 
>> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>> 
>> where this is the first "skill test" of many.
>> 
>> I, personally, cannot speak to the tools' status, whether functioning as
>> 
>> intended or not. I do not use them and do not know the code. They are as
>> 
>> they were, as far as the code is concerned.
>> 
>> Thanks,
>> 
>> -Noah
>> 
>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>> 
>> That may be the case, but I checked with Noah and Chris on Friday -
>> 
>> while the larger thread was still unspooling - and I've reported what
>> 
>> they told me then. If I misunderstood, happy to hear it.
>> 
>> ~Clay
>> 
>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <david.horwitz at uct.ac.za>
>> 
>> wrote:
>> 
>> Hi Clay
>> 
>> One point of clarity bellow
>> 
>> 1) OSP reports and warehouse tools - OSP is outside of the maintenance
>> 
>> team coverage and parts of it are beyond our capacity to maintain. We
>> 
>> recommend these be removed from the build.
>> 
>> This looks to me hasty. The fact that it is outside the MT's capacity
>> 
>> to maintain does not strike me as a decisive argument. It comes a
>> 
>> little too close to asking the code to conform to the shape of the MT
>> 
>> rather than the other way around, and it might be a better answer to
>> 
>> recruit broader expertise for the MT. I don't think it's imagined that
>> 
>> all maintenance would be completed by the maintenance team, especially
>> 
>> during these formative stages of its growth.
>> 
>> Now, if the MT can't maintain it *and* there is no other community
>> 
>> resource that can help, that's a stronger case. But as I understand it
>> 
>> the blocker issues for Reports are going to be examined by Noah, who
>> 
>> thinks it might be corrected by backing out some earlier work, while
>> 
>> we've heard that IU uses Reports in production.  My impression is that
>> 
>> the apparent lack of community support is a matter of slowness in
>> 
>> responding to this blocker, not that we have no remedy.
>> 
>> We should probably take John Bush's insight to heart, that we should
>> 
>> be looking for better solutions longer term. But dropping these for
>> 
>> 2.7 seems to me precipitous at this stage of the release cycle.
>> 
>> 
>> 
>> The MT recommendation was made in support of Alan's recommendation on
>> 
>> the 10th, that in turn was based on Noah's submission (as I understand
>> 
>> it) that the OSP team was unable to support these tools.
>> 
>> 
>> Regards
>> 
>> David
>> 
>> 
>> _______________________________________________
>> 
>> management mailing list
>> 
>> management at collab.sakaiproject.org
>> 
>> http://collab.sakaiproject.org/mailman/listinfo/management
>> 
>> TO UNSUBSCRIBE: send email to
>> 
>> management-unsubscribe at collab.sakaiproject.org with a subject of
>> 
>> "unsubscribe"
>> 
>> _______________________________________________
>> 
>> management mailing list
>> 
>> management at collab.sakaiproject.org
>> 
>> http://collab.sakaiproject.org/mailman/listinfo/management
>> 
>> TO UNSUBSCRIBE: send email to
>> 
>> management-unsubscribe at collab.sakaiproject.org with a subject of
>> 
>> "unsubscribe"
>> 
>> 
>> _______________________________________________
>> management mailing list
>> management at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/management
>> 
>> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
>> with a subject of "unsubscribe"
>> 
>> 
>> 
>> 
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100317/ea1190aa/attachment.bin

More information about the sakai-dev mailing list