[Deploying Sakai] [Building Sakai] [Management] FW: MT deprecation recommendations for 2.7 (fwd)

Fri Mar 12 15:50:23 PST 2010

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/

I could write more but bedtime is long overdue.

Cheers,

Anthony

On Mar 13, 2010, at 12:00 AM, Clay Fenlason wrote:

> I've been a little puzzled about why these recommendations are for 2.7
> as well. How this came about was that the Product Council has some
> Sakai 2 tools in incubation, and we were talking about them in the
> context of additions to new Sakai releases in future. David Horwitz
> made the very good point on the management list [1] that we should be
> thinking about subtractions as well as additions. Since the
> maintenance team is well positioned to see where the maintenance
> challenges are, I answered by asking a question: if the team might be
> able to make some recommendations. I'm grateful that they've done so.
> But coming from that context I had also imagined that we would be
> talking about the post-2.7 case, and could think them through
> carefully over an extended time. That these have become 2.7
> recommendations has, I'll admit, caught me off guard.
> 
> Apart from that, I'm not certain why it should be alarming that anyone
> is making recommendations. Recommendations are not binding, anyone
> could be offering them, but these do offer some perspective from those
> closest to the code. It's at the very least a good conversation
> starter. We don't, for example, have a clear and documented
> deprecation policy, and this set of examples provides a good
> opportunity to talk through cases and try to arrive at such clarity.
> 
> 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 - that we can iterate on and come to some consensus. I'd
> encourage us all to weigh in on these recommendations, and I've got
> some of my own thoughts to put forward on the particulars, but for the
> moment let me just reassure that no one is about to do anything
> precipitous.
> 
> ~Clay
> 
> [1] http://n2.nabble.com/Product-Council-Meeting-Reminder-tt4621838.html#a4621838
> 
> On Fri, Mar 12, 2010 at 4:03 PM, May, Megan Marie <mmmay at indiana.edu> wrote:
>> I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.
>> 
>> The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.
>> 
>> Megan
>> 
>> 
>> [1] http://confluence.sakaiproject.org/display/MNT/process
>> 
>> 
>> 
>> ---------- original message ----------
>> Date: Fri, 12 Mar 2010 13:25:04 +0000
>> From: Aaron Zeckoski <azeckoski at unicon.net>
>> To: Clay Fenlason <clay.fenlason at et.gatech.edu>
>> Cc: management at collab.sakaiproject.org, plumbers at sakaifoundation.org
>> Subject: MT deprecation recommendations for 2.7
>> 
>> Product Council,
>> 
>> The maintenance team (MT) has discussed what should be deprecated for
>> 2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
>> release.
>> 
>> When we say "remove from the build" we mean that the tools should
>> remain in the checkout (exports) but they will not be built and
>> deployed. Schools which need these tools can uncomment their entries
>> in the main pom file.
>> When we say "remove from the release" we mean the tool would not be in
>> the build or checkout. It would optionally be moved over to the
>> contrib space after the 2.7 release is complete.
>> 
>> Here are our recommendations:
>> 
>> 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.
>> 
>> 2) Mailtool - This has already been deprecated and has a number of
>> outstanding issues and no maintainers. We recommend it be removed from
>> the release. Mailsender will be added to the experimental build as a
>> replacement option but not enabled in a default build.
>> 
>> 3) Blog 1 (blogger) - This is not being maintained, has many
>> outstanding issues, and there are 2 possible replacement options. We
>> recommend it be removed from the release. We are still reviewing the
>> replacement options (blog 2 wicket and blogwow) and will have a firm
>> recommendation next week.
>> 
>> 4) Profile 1 tool - Profile 2 is already in place as the replacement
>> for 2.7 however there are still dependencies on Profile 1 tool in the
>> codebase. MT will remove these. We recommend the profile 1 tool be
>> removed from the release.
>> 
>> 5) Presentation tool - This has been deprecated and is not being
>> maintained. We recommend this be removed from the release.
>> 
>> 6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
>> burden and does not appear to be used. It increases the memory profile
>> and complexity of the kernel even when not in use. We recommend it be
>> removed from the release. JCR was meant as a possible replacement for
>> the content hosting service but this was not completed and there is no
>> one to maintain this code.
>> 
>> 7) Static covers - The covers are out of date (missing methods) and
>> not being maintained. Use of these has been discouraged since 2006. We
>> recommend these be marked as deprecated. We will also send a note to
>> the dev list to discourage their use clearly. The MT (and others) will
>> replace usage of these as they are encountered.
>> 
>> 8) Kernel utils - These homegrown utils tend to duplicate other open
>> source libraries. They also have issues in the way they are
>> implemented and sometimes even duplicate their own functionality. We
>> recommend the duplicative ones be marked as deprecated. MT (and
>> others) will replace these with usage of open source libraries as it
>> is encountered. Some kernel utils will be updated to use the open
>> source libraries by the MT. MT will also send a note to the dev list
>> to discourage the usage of deprecated kernel utils.
>> 
>> Thank you
>> -AZ
>> MT lead
>> http://confluence.sakaiproject.org/display/MNT
>> 
>> 
>> _______________________________________________
>> production mailing list
>> production at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/production
>> 
>> TO UNSUBSCRIBE: send email to production-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/production/attachments/20100313/ddeb80be/attachment.bin 