![]() |
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 _______________________________________________ management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() |
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 <[hidden email]> 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 > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() |
See bellow
> 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? > > This is in fact a formalization of work that started a while back. Some methods where marked in 1.0 kernel. All the javadoc deprecation noticed list the commons-lang method their equivalent to. > 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 > <[hidden email]> 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 >> >> > _______________________________________________ > management mailing list > [hidden email] > http://collab.sakaiproject.org/mailman/listinfo/management > > TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Aaron Zeckoski-3 |
![]() |
In reply to this post by Clay Fenlason
> 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 <[hidden email]> 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 > <[hidden email]> 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 > [hidden email] > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev > > TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" > -- Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile _______________________________________________ management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Clay Fenlason |
![]() |
Some comments in-line:
On Wed, Mar 24, 2010 at 10:14 AM, Aaron Zeckoski <[hidden email]> wrote: >> 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. > Right, but just so I'm clear (though I suspect this isn't really a question for Aaron, I don't want the question to be lost), is it the case that: a) Profile classic is still in 2.7.x? b) if you unstealth it, it should continue to function as before? > 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 > <[hidden email]> 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 >> <[hidden email]> 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 >> [hidden email] >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >> >> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" >> > > > > -- > Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
David Horwitz |
![]() |
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 >> <[hidden email]> 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 >>> <[hidden email]> 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 >>> [hidden email] >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >>> >>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" >>> >>> >> >> >> -- >> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile >> >> > _______________________________________________ > sakai-dev mailing list > [hidden email] > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev > > TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Clay Fenlason |
![]() |
OK, got it. Thanks.
~Clay On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]> 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 >>> <[hidden email]> 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 >>>> <[hidden email]> 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 >>>> [hidden email] >>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >>>> >>>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" >>>> >>>> >>> >>> >>> -- >>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile >>> >>> >> _______________________________________________ >> sakai-dev mailing list >> [hidden email] >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >> >> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" >> > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Steve Swinsburg-3 |
![]() |
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:
_______________________________________________ management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Clay Fenlason |
![]() |
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 <[hidden email]> 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 <[hidden email]> > 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 > > <[hidden email]> 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 > > <[hidden email]> 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 > > [hidden email] > > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev > > TO UNSUBSCRIBE: send email to [hidden email] > with a subject of "unsubscribe" > > > > > -- > > Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile > > > _______________________________________________ > > sakai-dev mailing list > > [hidden email] > > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev > > TO UNSUBSCRIBE: send email to [hidden email] > with a subject of "unsubscribe" > > > _______________________________________________ > management mailing list > [hidden email] > http://collab.sakaiproject.org/mailman/listinfo/management > > TO UNSUBSCRIBE: send email to [hidden email] > with a subject of "unsubscribe" > > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Steve Swinsburg-3 |
![]() |
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 > <[hidden email]> 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 <[hidden email]> >> 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 >> >> <[hidden email]> 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 >> >> <[hidden email]> 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 >> >> [hidden email] >> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >> >> TO UNSUBSCRIBE: send email to [hidden email] >> with a subject of "unsubscribe" >> >> >> >> >> -- >> >> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile >> >> >> _______________________________________________ >> >> sakai-dev mailing list >> >> [hidden email] >> >> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >> >> TO UNSUBSCRIBE: send email to [hidden email] >> with a subject of "unsubscribe" >> >> >> _______________________________________________ >> management mailing list >> [hidden email] >> http://collab.sakaiproject.org/mailman/listinfo/management >> >> TO UNSUBSCRIBE: send email to [hidden email] >> with a subject of "unsubscribe" >> >> > _______________________________________________ > management mailing list > [hidden email] > http://collab.sakaiproject.org/mailman/listinfo/management > > TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" _______________________________________________ management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
![]() ![]() |
Clay Fenlason |
![]() |
Terrific. Thanks for your extra work that went toward this peaceful coexistence.
~Clay On Wed, Mar 24, 2010 at 7:09 PM, Steve Swinsburg <[hidden email]> 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 >> <[hidden email]> 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 <[hidden email]> >>> 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 >>> >>> <[hidden email]> 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 >>> >>> <[hidden email]> 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 >>> >>> [hidden email] >>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >>> >>> TO UNSUBSCRIBE: send email to [hidden email] >>> with a subject of "unsubscribe" >>> >>> >>> >>> >>> -- >>> >>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile >>> >>> >>> _______________________________________________ >>> >>> sakai-dev mailing list >>> >>> [hidden email] >>> >>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev >>> >>> TO UNSUBSCRIBE: send email to [hidden email] >>> with a subject of "unsubscribe" >>> >>> >>> _______________________________________________ >>> management mailing list >>> [hidden email] >>> http://collab.sakaiproject.org/mailman/listinfo/management >>> >>> TO UNSUBSCRIBE: send email to [hidden email] >>> with a subject of "unsubscribe" >>> >>> >> _______________________________________________ >> management mailing list >> [hidden email] >> http://collab.sakaiproject.org/mailman/listinfo/management >> >> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" > > management mailing list [hidden email] http://collab.sakaiproject.org/mailman/listinfo/management TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe" |
Free forum by Nabble | Edit this page |