[Building Sakai] Deprecation summary page

Aaron Zeckoski azeckoski at unicon.net
Wed Mar 24 07:14:02 PDT 2010


> 4) I confess to a bit of uncertainty about the state of the two
> Profile tools. I was under the impression in December [2] that the two
> profiles couldn't work together, but it looks like Steve managed to
> complete the work that allowed them to do so [3]. And yet something
> about Aaron's description of removing remaining dependencies to
> Profile 1 makes me wonder if in fact they can still be swapped with
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
> the proposal to simply say that Profile classic should be stealthed
> and marked as deprecated.

The issue is not with profile 1 itself but with other tools like
roster that have a direct dependency on the profile 1 tool. Aside from
tool to tool dependencies being a poor practice it also makes it
impossible for someone to remove the profile 1 tool if they are not
using it (without removing all the tools that depend on it). At an
absolute minimum we need to remove these dependencies.

There isn't really a way to mark a tool as deprecated.

-AZ


On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
<clay.fenlason at et.gatech.edu> wrote:
> Some outstanding questions I'd like to get more comment on:
>
> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
> about this?
>
> 2) I've tried to represent the JCR and Static Cover issues as well as
> I understand them [1], but would welcome clarity from my betters. At
> the time of this writing, we're still ping-ponging the issue of
> whether to actually flag static covers as deprecated, but seem to have
> come to agreement on the rest (retain them, but remove their use from
> core code).
>
> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
> not, for example, explain if anything will be done for 2.7. I'm
> inclined to think that this would be appropriate for kernel 1.2, but
> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
> 3rd-party utils?
>
> 4) I confess to a bit of uncertainty about the state of the two
> Profile tools. I was under the impression in December [2] that the two
> profiles couldn't work together, but it looks like Steve managed to
> complete the work that allowed them to do so [3]. And yet something
> about Aaron's description of removing remaining dependencies to
> Profile 1 makes me wonder if in fact they can still be swapped with
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
> the proposal to simply say that Profile classic should be stealthed
> and marked as deprecated.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>
> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
> <clay.fenlason at et.gatech.edu> wrote:
>> I'd promised I was going to work this up this past weekend, but I've
>> been sick the last few days, and it's been delayed. Still not quite
>> finished, but I'm feeling poorly again and need to rest a bit, so I
>> won't delay circulating the link [1]. The latest on JCR and Static
>> covers still isn't there.
>>
>> Comments and other edits of course welcome.
>>
>> HTH
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>
> _______________________________________________
> 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"
>



-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile


More information about the sakai-dev mailing list