[WG: Sakai QA] [Management] MT deprecation recommendations for 2.7

Berg, Alan A.M.Berg at uva.nl
Sun Mar 14 23:51:58 PDT 2010 

+1

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg


+1


-----Original Message-----
From: management-bounces at collab.sakaiproject.org on behalf of Anthony Whyte
Sent: Mon 3/15/2010 0:40
To: Clay Fenlason
Cc: management at collab.sakaiproject.org; Sakai QA; Developers Sakai-Dev
Subject: Re: [Management] MT deprecation recommendations for 2.7
 
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"
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20100315/6d137325/attachment-0001.html

More information about the sakai-qa mailing list