[Building Sakai] Deprecation Notice: kernel static covers

Wed Mar 17 05:10:57 PDT 2010

on the lifecycle time line there is no clear date for kernel 2.0 - In
effect it would be the release in which this and some other methods
already marked for deprecation would be removed. Both the MT and the
community have a fair bit of work to remove the use of them from the
main code I don't think it will be for at least a year at the very
earliest. Obviously there would be community involvement in the decision
making.

This has been debated at length and have seen nothing that suggests that
they should not be removed after a sufficient deprecation time.

D

On 03/17/2010 01:05 PM, Berg, Alan wrote:
> Hi all,
>
> I see this as life cycle management. Depreciation allows aging API's that have known weaknesses to be gracefully retired.
>
>   
>> Maintenance activities should represent a net gain of time and productivity to the community, not a net loss.
>>     
> Overtime as specific code is replaced and uses spring injection and more unit tests the confidence in the code base increases and code becomes less brittle as issues are spotted earlier. This will save the MT some maintenance drag. It is a balance between moving a product on and costs of change. Therefore the question is the API ripe for the depreciation process or is it the time to removal that is the issue.
>
> 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
>
>
>
>
> -----Original Message-----
> From: Stephen Marquard [mailto:stephen.marquard at uct.ac.za]
> Sent: Wed 3/17/2010 11:49
> To: Steve Swinsburg; Berg, Alan
> Cc: sakai-dev List
> Subject: Re: [Building Sakai] Deprecation Notice: kernel static covers
>  
> In the context of the static covers specifically, they are not "better APIs" than the regular APIs, they are the same. They have practical difference when you care about unit testing, etc.
>
> It may be extremely simple to convert them, but it represents time for every institution with local code that is forced to do so by their removal, which is unnecessary. So removing them is effectively imposing a tax on the Sakai community (say 100 hours or so of collective effort, possibly greater).
>
> Maintenance activities should represent a net gain of time and productivity to the community, not a net loss.
>
> Regards
> Stephen
>
>   
>>>> Steve Swinsburg <steve.swinsburg at gmail.com> 3/17/2010 12:38 PM >>>
>>>>         
> Hi all,
>
> What is the rough timeline for Kernel 2.0.0? 
>
> The comment about web services always comes up when discussing the deprecation/removal of the static covers. In reality, converting these over to use the normal API's is extremely simple using the ComponentManager: http://jira.sakaiproject.org/browse/SAK-16323.
>
> Steve
>
> On 17/03/2010, at 9:26 PM, Berg, Alan wrote:
>
>   
>> Hi,
>>
>> I beg to disagree, I believe that there should be a clear predictable time between start of depreciation and end. The whole process is supposed to give time to transition from depreciated API to better API. The static covers make for complex dependencies and make unit testing difficult and so are a good case for depreciation. Therefore the question is do disagree with depreciation or the TTL.
>>
>> 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 
>>
>>
>>
>>
>> -----Original Message-----
>> From: sakai-dev-bounces at collab.sakaiproject.org on behalf of Stephen Marquard
>> Sent: Wed 3/17/2010 11:03
>> To: sakai-dev
>> Subject: Re: [Building Sakai] Deprecation Notice: kernel static covers
>>
>> As a local implementer and kernel team member, I object and vote -1 on eventual removal of the static covers, as this imposes an unnecessary code maintenance burden on local sites, especially wrt third-party code (for example locally maintained webservices and other code).
>>
>> I have no problem with these being deprecated, but they should be left in place indefinitely.
>>
>> Regards
>> Stephen
>>
>>     
>>>>> David Horwitz <david.horwitz at uct.ac.za> 3/17/2010 10:04 AM >>>
>>>>>           
>> Deprecation Notice: In the next scheduled release in the 1.1 kernel series (1.1.2) all the Static covers of kernel services will be marked as deprecated. Developers are urged to review their code and replace the use of static covers with spring injection or lookup from the component manager in line with stated Sakai best practices [http://confluence.sakaiproject.org/display/SAKDEV/Best+Practices+for+Kernel+code#BestPracticesforKernelcode-Nousageofstaticcovers]. The covers are scheduled for removal in Kernel 2.0.0
>>
>> Regards
>>
>> David
>>
>> _______________________________________________
>> 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"
>>
>>
>>
>> ______________________________________________________________________________________________
>>
>> UNIVERSITY OF CAPE TOWN
>>
>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>>
>> _____________________________________________________________________________________________________
>>
>> _______________________________________________
>> 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"
>>
>>
>> _______________________________________________
>> 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"
>>     
>
>
>  
> ______________________________________________________________________________________________ 
>
> UNIVERSITY OF CAPE TOWN 
>
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>
> _____________________________________________________________________________________________________
>  
>
>
>   
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100317/72b4f930/attachment.html 