[Building Sakai] [Management] Deprecation summary page

Steve Swinsburg steve.swinsburg at gmail.com
Wed Mar 24 16:09:06 PDT 2010 

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"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3689 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100325/a79e979d/attachment.bin

More information about the sakai-dev mailing list