FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

classic Classic list List threaded Threaded
4 messages Options
May, Megan Marie May, Megan Marie
Reply | Threaded
Open this post in threaded view
|

FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.

The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.    

Megan


[1] http://confluence.sakaiproject.org/display/MNT/process 



---------- original message ----------
Date: Fri, 12 Mar 2010 13:25:04 +0000
From: Aaron Zeckoski <[hidden email]>
To: Clay Fenlason <[hidden email]>
Cc: [hidden email], [hidden email]
Subject: MT deprecation recommendations for 2.7

Product Council,

The maintenance team (MT) has discussed what should be deprecated for
2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
release.

When we say "remove from the build" we mean that the tools should
remain in the checkout (exports) but they will not be built and
deployed. Schools which need these tools can uncomment their entries
in the main pom file.
When we say "remove from the release" we mean the tool would not be in
the build or checkout. It would optionally be moved over to the
contrib space after the 2.7 release is complete.

Here are our recommendations:

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.

2) Mailtool - This has already been deprecated and has a number of
outstanding issues and no maintainers. We recommend it be removed from
the release. Mailsender will be added to the experimental build as a
replacement option but not enabled in a default build.

3) Blog 1 (blogger) - This is not being maintained, has many
outstanding issues, and there are 2 possible replacement options. We
recommend it be removed from the release. We are still reviewing the
replacement options (blog 2 wicket and blogwow) and will have a firm
recommendation next week.

4) Profile 1 tool - Profile 2 is already in place as the replacement
for 2.7 however there are still dependencies on Profile 1 tool in the
codebase. MT will remove these. We recommend the profile 1 tool be
removed from the release.

5) Presentation tool - This has been deprecated and is not being
maintained. We recommend this be removed from the release.

6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
burden and does not appear to be used. It increases the memory profile
and complexity of the kernel even when not in use. We recommend it be
removed from the release. JCR was meant as a possible replacement for
the content hosting service but this was not completed and there is no
one to maintain this code.

7) Static covers - The covers are out of date (missing methods) and
not being maintained. Use of these has been discouraged since 2006. We
recommend these be marked as deprecated. We will also send a note to
the dev list to discourage their use clearly. The MT (and others) will
replace usage of these as they are encountered.

8) Kernel utils - These homegrown utils tend to duplicate other open
source libraries. They also have issues in the way they are
implemented and sometimes even duplicate their own functionality. We
recommend the duplicative ones be marked as deprecated. MT (and
others) will replace these with usage of open source libraries as it
is encountered. Some kernel utils will be updated to use the open
source libraries by the MT. MT will also send a note to the dev list
to discourage the usage of deprecated kernel utils.

Thank you
-AZ
MT lead
http://confluence.sakaiproject.org/display/MNT


_______________________________________________
production mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/production

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 Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

I've been a little puzzled about why these recommendations are for 2.7
as well. How this came about was that the Product Council has some
Sakai 2 tools in incubation, and we were talking about them in the
context of additions to new Sakai releases in future. David Horwitz
made the very good point on the management list [1] that we should be
thinking about subtractions as well as additions. Since the
maintenance team is well positioned to see where the maintenance
challenges are, I answered by asking a question: if the team might be
able to make some recommendations. I'm grateful that they've done so.
But coming from that context I had also imagined that we would be
talking about the post-2.7 case, and could think them through
carefully over an extended time. That these have become 2.7
recommendations has, I'll admit, caught me off guard.

Apart from that, I'm not certain why it should be alarming that anyone
is making recommendations. Recommendations are not binding, anyone
could be offering them, but these do offer some perspective from those
closest to the code. It's at the very least a good conversation
starter. We don't, for example, have a clear and documented
deprecation policy, and this set of examples provides a good
opportunity to talk through cases and try to arrive at such clarity.

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 - that we can iterate on and come to some consensus. I'd
encourage us all to weigh in on these recommendations, and I've got
some of my own thoughts to put forward on the particulars, but for the
moment let me just reassure that no one is about to do anything
precipitous.

~Clay

[1] http://n2.nabble.com/Product-Council-Meeting-Reminder-tt4621838.html#a4621838

On Fri, Mar 12, 2010 at 4:03 PM, May, Megan Marie <[hidden email]> wrote:

> I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.
>
> The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.
>
> Megan
>
>
> [1] http://confluence.sakaiproject.org/display/MNT/process
>
>
>
> ---------- original message ----------
> Date: Fri, 12 Mar 2010 13:25:04 +0000
> From: Aaron Zeckoski <[hidden email]>
> To: Clay Fenlason <[hidden email]>
> Cc: [hidden email], [hidden email]
> Subject: MT deprecation recommendations for 2.7
>
> Product Council,
>
> The maintenance team (MT) has discussed what should be deprecated for
> 2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
> release.
>
> When we say "remove from the build" we mean that the tools should
> remain in the checkout (exports) but they will not be built and
> deployed. Schools which need these tools can uncomment their entries
> in the main pom file.
> When we say "remove from the release" we mean the tool would not be in
> the build or checkout. It would optionally be moved over to the
> contrib space after the 2.7 release is complete.
>
> Here are our recommendations:
>
> 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.
>
> 2) Mailtool - This has already been deprecated and has a number of
> outstanding issues and no maintainers. We recommend it be removed from
> the release. Mailsender will be added to the experimental build as a
> replacement option but not enabled in a default build.
>
> 3) Blog 1 (blogger) - This is not being maintained, has many
> outstanding issues, and there are 2 possible replacement options. We
> recommend it be removed from the release. We are still reviewing the
> replacement options (blog 2 wicket and blogwow) and will have a firm
> recommendation next week.
>
> 4) Profile 1 tool - Profile 2 is already in place as the replacement
> for 2.7 however there are still dependencies on Profile 1 tool in the
> codebase. MT will remove these. We recommend the profile 1 tool be
> removed from the release.
>
> 5) Presentation tool - This has been deprecated and is not being
> maintained. We recommend this be removed from the release.
>
> 6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
> burden and does not appear to be used. It increases the memory profile
> and complexity of the kernel even when not in use. We recommend it be
> removed from the release. JCR was meant as a possible replacement for
> the content hosting service but this was not completed and there is no
> one to maintain this code.
>
> 7) Static covers - The covers are out of date (missing methods) and
> not being maintained. Use of these has been discouraged since 2006. We
> recommend these be marked as deprecated. We will also send a note to
> the dev list to discourage their use clearly. The MT (and others) will
> replace usage of these as they are encountered.
>
> 8) Kernel utils - These homegrown utils tend to duplicate other open
> source libraries. They also have issues in the way they are
> implemented and sometimes even duplicate their own functionality. We
> recommend the duplicative ones be marked as deprecated. MT (and
> others) will replace these with usage of open source libraries as it
> is encountered. Some kernel utils will be updated to use the open
> source libraries by the MT. MT will also send a note to the dev list
> to discourage the usage of deprecated kernel utils.
>
> Thank you
> -AZ
> MT lead
> http://confluence.sakaiproject.org/display/MNT
>
>
> _______________________________________________
> production mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> 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"
Anthony Whyte Anthony Whyte
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] 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/

I could write more but bedtime is long overdue.

Cheers,

Anthony



On Mar 13, 2010, at 12:00 AM, Clay Fenlason wrote:

> I've been a little puzzled about why these recommendations are for 2.7
> as well. How this came about was that the Product Council has some
> Sakai 2 tools in incubation, and we were talking about them in the
> context of additions to new Sakai releases in future. David Horwitz
> made the very good point on the management list [1] that we should be
> thinking about subtractions as well as additions. Since the
> maintenance team is well positioned to see where the maintenance
> challenges are, I answered by asking a question: if the team might be
> able to make some recommendations. I'm grateful that they've done so.
> But coming from that context I had also imagined that we would be
> talking about the post-2.7 case, and could think them through
> carefully over an extended time. That these have become 2.7
> recommendations has, I'll admit, caught me off guard.
>
> Apart from that, I'm not certain why it should be alarming that anyone
> is making recommendations. Recommendations are not binding, anyone
> could be offering them, but these do offer some perspective from those
> closest to the code. It's at the very least a good conversation
> starter. We don't, for example, have a clear and documented
> deprecation policy, and this set of examples provides a good
> opportunity to talk through cases and try to arrive at such clarity.
>
> 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 - that we can iterate on and come to some consensus. I'd
> encourage us all to weigh in on these recommendations, and I've got
> some of my own thoughts to put forward on the particulars, but for the
> moment let me just reassure that no one is about to do anything
> precipitous.
>
> ~Clay
>
> [1] http://n2.nabble.com/Product-Council-Meeting-Reminder-tt4621838.html#a4621838
>
> On Fri, Mar 12, 2010 at 4:03 PM, May, Megan Marie <[hidden email]> wrote:
>> I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.
>>
>> The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.
>>
>> Megan
>>
>>
>> [1] http://confluence.sakaiproject.org/display/MNT/process
>>
>>
>>
>> ---------- original message ----------
>> Date: Fri, 12 Mar 2010 13:25:04 +0000
>> From: Aaron Zeckoski <[hidden email]>
>> To: Clay Fenlason <[hidden email]>
>> Cc: [hidden email], [hidden email]
>> Subject: MT deprecation recommendations for 2.7
>>
>> Product Council,
>>
>> The maintenance team (MT) has discussed what should be deprecated for
>> 2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
>> release.
>>
>> When we say "remove from the build" we mean that the tools should
>> remain in the checkout (exports) but they will not be built and
>> deployed. Schools which need these tools can uncomment their entries
>> in the main pom file.
>> When we say "remove from the release" we mean the tool would not be in
>> the build or checkout. It would optionally be moved over to the
>> contrib space after the 2.7 release is complete.
>>
>> Here are our recommendations:
>>
>> 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.
>>
>> 2) Mailtool - This has already been deprecated and has a number of
>> outstanding issues and no maintainers. We recommend it be removed from
>> the release. Mailsender will be added to the experimental build as a
>> replacement option but not enabled in a default build.
>>
>> 3) Blog 1 (blogger) - This is not being maintained, has many
>> outstanding issues, and there are 2 possible replacement options. We
>> recommend it be removed from the release. We are still reviewing the
>> replacement options (blog 2 wicket and blogwow) and will have a firm
>> recommendation next week.
>>
>> 4) Profile 1 tool - Profile 2 is already in place as the replacement
>> for 2.7 however there are still dependencies on Profile 1 tool in the
>> codebase. MT will remove these. We recommend the profile 1 tool be
>> removed from the release.
>>
>> 5) Presentation tool - This has been deprecated and is not being
>> maintained. We recommend this be removed from the release.
>>
>> 6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
>> burden and does not appear to be used. It increases the memory profile
>> and complexity of the kernel even when not in use. We recommend it be
>> removed from the release. JCR was meant as a possible replacement for
>> the content hosting service but this was not completed and there is no
>> one to maintain this code.
>>
>> 7) Static covers - The covers are out of date (missing methods) and
>> not being maintained. Use of these has been discouraged since 2006. We
>> recommend these be marked as deprecated. We will also send a note to
>> the dev list to discourage their use clearly. The MT (and others) will
>> replace usage of these as they are encountered.
>>
>> 8) Kernel utils - These homegrown utils tend to duplicate other open
>> source libraries. They also have issues in the way they are
>> implemented and sometimes even duplicate their own functionality. We
>> recommend the duplicative ones be marked as deprecated. MT (and
>> others) will replace these with usage of open source libraries as it
>> is encountered. Some kernel utils will be updated to use the open
>> source libraries by the MT. MT will also send a note to the dev list
>> to discourage the usage of deprecated kernel utils.
>>
>> Thank you
>> -AZ
>> MT lead
>> http://confluence.sakaiproject.org/display/MNT
>>
>>
>> _______________________________________________
>> production mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/production
>>
>> 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"
>>
> _______________________________________________
> 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"

smime.p7s (3K) Download Attachment
May, Megan Marie May, Megan Marie
Reply | Threaded
Open this post in threaded view
|

Re: FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

In reply to this post by Clay Fenlason
I'm not sure what is meant by 'alarming.'   My point is that there is no clarity when it comes to understanding what to expect as the community ramps up for a software release, how decisions are made and when the community should expect (rely on?) the varying teams to be involved.  

As someone that used to live and breathe this stuff, it increasingly seems as if we've flying by the seat of our pants.  Perhaps it has always been this way and I've gained some clarity with distance.  Regardless, I think these are points that should be crystal clear to the entire community.    

Just my 2 cents,
Megan
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Clay Fenlason
Sent: Friday, March 12, 2010 5:01 PM
To: May, Megan Marie
Cc: [hidden email]; [hidden email]; [hidden email] Developers
Subject: Re: [Management] FW: [Deploying Sakai] MT deprecation recommendations for 2.7 (fwd)

I've been a little puzzled about why these recommendations are for 2.7
as well. How this came about was that the Product Council has some
Sakai 2 tools in incubation, and we were talking about them in the
context of additions to new Sakai releases in future. David Horwitz
made the very good point on the management list [1] that we should be
thinking about subtractions as well as additions. Since the
maintenance team is well positioned to see where the maintenance
challenges are, I answered by asking a question: if the team might be
able to make some recommendations. I'm grateful that they've done so.
But coming from that context I had also imagined that we would be
talking about the post-2.7 case, and could think them through
carefully over an extended time. That these have become 2.7
recommendations has, I'll admit, caught me off guard.

Apart from that, I'm not certain why it should be alarming that anyone
is making recommendations. Recommendations are not binding, anyone
could be offering them, but these do offer some perspective from those
closest to the code. It's at the very least a good conversation
starter. We don't, for example, have a clear and documented
deprecation policy, and this set of examples provides a good
opportunity to talk through cases and try to arrive at such clarity.

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 - that we can iterate on and come to some consensus. I'd
encourage us all to weigh in on these recommendations, and I've got
some of my own thoughts to put forward on the particulars, but for the
moment let me just reassure that no one is about to do anything
precipitous.

~Clay

[1] http://n2.nabble.com/Product-Council-Meeting-Reminder-tt4621838.html#a4621838

On Fri, Mar 12, 2010 at 4:03 PM, May, Megan Marie <[hidden email]> wrote:

> I confused by the fact that the maintenance team is providing recommendations for the 2.7 release.  According to the maintenance team confluence space [1] the MT does not work on release management or branch management.  While it makes sense that this team should weigh in on whether or not they have resources, is that really the charge of this group?  I would expect that a recommendation would come from the release management team.
>
> The process and involvement of groups/teams in software releases is becoming increasingly unclear, undocumented and un-communicated.  Could we get some clarity around this? It's extremely hard to get a handle on 2.7 when this isn't known.
>
> Megan
>
>
> [1] http://confluence.sakaiproject.org/display/MNT/process
>
>
>
> ---------- original message ----------
> Date: Fri, 12 Mar 2010 13:25:04 +0000
> From: Aaron Zeckoski <[hidden email]>
> To: Clay Fenlason <[hidden email]>
> Cc: [hidden email], [hidden email]
> Subject: MT deprecation recommendations for 2.7
>
> Product Council,
>
> The maintenance team (MT) has discussed what should be deprecated for
> 2.7 over the past 2 weeks. These are recommendations for the Sakai 2.7
> release.
>
> When we say "remove from the build" we mean that the tools should
> remain in the checkout (exports) but they will not be built and
> deployed. Schools which need these tools can uncomment their entries
> in the main pom file.
> When we say "remove from the release" we mean the tool would not be in
> the build or checkout. It would optionally be moved over to the
> contrib space after the 2.7 release is complete.
>
> Here are our recommendations:
>
> 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.
>
> 2) Mailtool - This has already been deprecated and has a number of
> outstanding issues and no maintainers. We recommend it be removed from
> the release. Mailsender will be added to the experimental build as a
> replacement option but not enabled in a default build.
>
> 3) Blog 1 (blogger) - This is not being maintained, has many
> outstanding issues, and there are 2 possible replacement options. We
> recommend it be removed from the release. We are still reviewing the
> replacement options (blog 2 wicket and blogwow) and will have a firm
> recommendation next week.
>
> 4) Profile 1 tool - Profile 2 is already in place as the replacement
> for 2.7 however there are still dependencies on Profile 1 tool in the
> codebase. MT will remove these. We recommend the profile 1 tool be
> removed from the release.
>
> 5) Presentation tool - This has been deprecated and is not being
> maintained. We recommend this be removed from the release.
>
> 6) JCR - The JCR/jackrabbit module in the kernel is a maintenance
> burden and does not appear to be used. It increases the memory profile
> and complexity of the kernel even when not in use. We recommend it be
> removed from the release. JCR was meant as a possible replacement for
> the content hosting service but this was not completed and there is no
> one to maintain this code.
>
> 7) Static covers - The covers are out of date (missing methods) and
> not being maintained. Use of these has been discouraged since 2006. We
> recommend these be marked as deprecated. We will also send a note to
> the dev list to discourage their use clearly. The MT (and others) will
> replace usage of these as they are encountered.
>
> 8) Kernel utils - These homegrown utils tend to duplicate other open
> source libraries. They also have issues in the way they are
> implemented and sometimes even duplicate their own functionality. We
> recommend the duplicative ones be marked as deprecated. MT (and
> others) will replace these with usage of open source libraries as it
> is encountered. Some kernel utils will be updated to use the open
> source libraries by the MT. MT will also send a note to the dev list
> to discourage the usage of deprecated kernel utils.
>
> Thank you
> -AZ
> MT lead
> http://confluence.sakaiproject.org/display/MNT
>
>
> _______________________________________________
> production mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> 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"