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

John Norman john at caret.cam.ac.uk
Thu Mar 18 03:09:36 PDT 2010 

Is someone keeping track of the pros and cons of the various proposals? If it comes to a decision in which I am asked for an opinion I would prefer to analyse something along the lines of:

Doing XXX provides the following savings/benefits [to whom]... and it has the following costs/disadvantages [to whom]

Thanks
John

On 17 Mar 2010, at 18:19, 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-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
> 
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

More information about the sakai-dev mailing list