[Building Sakai] [Management] Deprecation summary page

Wed Mar 24 16:12:35 PDT 2010

Terrific. Thanks for your extra work that went toward this peaceful coexistence.

~Clay

On Wed, Mar 24, 2010 at 7:09 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> Hi Clay,
>
> Yes everything you said is fine and is the track we are taking with this. See inline.
>
>> clear preference for 2.7 for Profile classic to remain as an option.
>
> I'm fine with leaving in Profile classic as an option, this is why I did the work for both to coexist side by side so that people had the choice.
>
>> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the interface)?
>
>
> The name of the Profile2 tool has been changed to be just 'Profile'.
>
> cheers,
> Steve
>
>
>
> On 25/03/2010, at 10:01 AM, Clay Fenlason wrote:
>
>> OK, good to know, but to be clear, I think it's the clear preference
>> for 2.7 for Profile classic to remain as an option. We have done
>> nothing in prior releases to signal its departure, and yanking it out
>> of 2.7 at this stage has the potential to be disruptive. It would be
>> surprising if someone missed it, but we should operate on that basis.
>>
>> Post-2.7, we should look at moving it from trunk to contrib. Perhaps
>> very soon post-2.7.
>>
>> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the
>> interface)? I think we should label both simply 'Profile,' and leave
>> it to institutions to configure for the classic version in the
>> unlikely event they opt to.
>>
>> ~Clay
>>
>> On Wed, Mar 24, 2010 at 6:08 PM, Steve Swinsburg
>> <steve.swinsburg at gmail.com> wrote:
>>>
>>> The actual Profile classic tool can be removed (ie the webapp).  As Aaron
>>> pointed out, Roster depends on the Profile classic API, so at the moment,
>>> that needs to stay.
>>> Profile2 provides an implementation of the ProfileManager that gets it's
>>> data from Profile2, so the Roster can use this instead. This is currently in
>>> place and can be switched around via an entry in sakai.properties:
>>>
>>> # Set this to tell the ProfileManager to get it's data from Profile2.
>>> # If left unset, any tools that use the ProfileManager from the original
>>> profile tool (ie Roster)
>>> # will continue to use the data from
>>> org.sakaiproject.api.app.profile.LegacyProfileManager.
>>> # So you must set this to enable the integrations.
>>> # If you are using a version of Sakai prior to 2.7, you need to apply the
>>> patch attached to
>>> # http://jira.sakaiproject.org/browse/SAK-17573 in order for this property
>>> to have any effect
>>> profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
>>>
>>> However, the Roster is still looking at the Profile/ProfileImpl models from
>>> the Profile classic API for it's information. Some work needs to be done
>>> with the Roster to abstract this part out to somewhere else.
>>> For now, we should be able to remove the profile classic tool and leave the
>>> API.
>>> cheers,
>>> Steve
>>>
>>> On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:
>>>
>>> OK, got it. Thanks.
>>>
>>> ~Clay
>>>
>>> On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <david.horwitz at uct.ac.za>
>>> wrote:
>>>
>>> Hi
>>>
>>> a) Profile classic is still in 2.7.x?
>>>
>>> yes
>>>
>>> b) if you unstealth it, it should continue to function as before?
>>>
>>>
>>> Because of the way its used "stealthed" doesn't realy apply to profile
>>>
>>> classic. You could leave it in your my workspaces templates and it would
>>>
>>> continue to work as before...
>>>
>>>
>>> D
>>>
>>>
>>> There isn't really a way to mark a tool as deprecated.
>>>
>>> In the policy draft I've put forward, tool deprecation entails:
>>>
>>> 1) Stealthing the tool
>>>
>>> 2) Listing it as deprecated in the release notes, and announcing the
>>>
>>> same on-list
>>>
>>> 3) Removing it to contrib in the next feature release, assuming there
>>>
>>> aren't extenuating circumstances that would argue for keeping it
>>>
>>> around longer (eg. if a migration path still needs to be worked out)
>>>
>>> ~Clay
>>>
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>>
>>> 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"
>>>
>>>
>>> _______________________________________________
>>> 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"
>
>