Re: MT deprecation recommendations for 2.7

classic Classic list List threaded Threaded
15 messages Options
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

Thanks for this, Aaron - and to the rest of the maintenance team. I'm
reminded that we don't have a clear, documented deprecation policy,
and this spread of cases gives us a good opportunity to think through
a comprehensive one, above and beyond the question of 2.7.

I'm taking it as a guiding principle that deprecation should not
generally mean peremptory removal, but that there is some sort of
flagging of the deprecated thing (in one version) that allows enough
time for those who may assume or rely on it to adapt or find
alternatives before it goes away (in a later version). I'm putting it
in that vague way because I think there is a functional dimension to
this.

We're of course generally reluctant to remove things because of the
danger of introducing regressions, and we're at a very late stage of
the QA cycle, but I don't think that point is lost on anyone, and I'm
assuming the MT has taken that into account (eg. dependencies and
potential regressions) in its recommendations.

Comments about particular items in-line below.

On Fri, Mar 12, 2010 at 8:25 AM, Aaron Zeckoski <[hidden email]> wrote:

> 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.

What concerns me about this approach is that it is made from the
perspective of those working directly with the code. I don't think we
can afford to  say that editing the main pom file provides a general
workaround for deprecating functionality. I think we have to imagine a
deployer who is working only with release binaries.

> 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.

This looks to me hasty. The fact that it is outside the MT's capacity
to maintain does not strike me as a decisive argument. It comes a
little too close to asking the code to conform to the shape of the MT
rather than the other way around, and it might be a better answer to
recruit broader expertise for the MT. I don't think it's imagined that
all maintenance would be completed by the maintenance team, especially
during these formative stages of its growth.

Now, if the MT can't maintain it *and* there is no other community
resource that can help, that's a stronger case. But as I understand it
the blocker issues for Reports are going to be examined by Noah, who
thinks it might be corrected by backing out some earlier work, while
we've heard that IU uses Reports in production.  My impression is that
the apparent lack of community support is a matter of slowness in
responding to this blocker, not that we have no remedy.

We should probably take John Bush's insight to heart, that we should
be looking for better solutions longer term. But dropping these for
2.7 seems to me precipitous at this stage of the release cycle.

> 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.

It's true that it has no maintainers, it's correct that it was already
deprecated in a prior release - I see this noted in the 2.6 release
notes [1], and so I'd agree that it's ready to be removed to contrib.

> 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.

Yes, it has no maintainers - Lancaster has been clear that its support
is limited to blog 2 - but I still believe we need a more measured and
predictable deprecation process that flags this tool as deprecated
before we remove it, and certainly before we swap in a different tool
in 2.7. AFAICT this hasn't been done as yet. I'd recommend stealthing
it, flagging it as deprecated in the release notes, and reviewing a
replacement as a 2.8 matter in future.

> 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.

This was wrestled with back in December. Again, I think it cuts
against the grain of a reasonable deprecation policy when a new tool
forcibly displaces another, but IIRC the consensus was that the legacy
profile tool was anemic enough that it wouldn't be missed, and it also
wasn't maintained, so in the final analysis the risk tradeoff came
down in Profile 2's favor in less than ideal circumstances. This
sounds to me like an extension of that cleanup operation.

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

According to the 2.6 release notes [1], this was already deprecated
and removed in 2.6 ... so I guess we just need to follow through?

> 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.

This seems to me certainly like a good candidate for something to not
be included in a checkout or build, since AFAIK it requires some
code-level expertise to even leverage in its current state.

> 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.

Sounds like the right approach to a strictly code-level problem.

> 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.

Ditto.

Picking up on my earlier point, I'm now going to try to codify the
arguments that have been raised on some of these points into some sort
of draft deprecation policy that we might come to consensus on.

~Clay

[1] http://confluence.sakaiproject.org//x/aQE5Ag
_______________________________________________
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 David Horwitz
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

Hi Clay

One point of clarity bellow

>> 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.
>>    
> This looks to me hasty. The fact that it is outside the MT's capacity
> to maintain does not strike me as a decisive argument. It comes a
> little too close to asking the code to conform to the shape of the MT
> rather than the other way around, and it might be a better answer to
> recruit broader expertise for the MT. I don't think it's imagined that
> all maintenance would be completed by the maintenance team, especially
> during these formative stages of its growth.
>
> Now, if the MT can't maintain it *and* there is no other community
> resource that can help, that's a stronger case. But as I understand it
> the blocker issues for Reports are going to be examined by Noah, who
> thinks it might be corrected by backing out some earlier work, while
> we've heard that IU uses Reports in production.  My impression is that
> the apparent lack of community support is a matter of slowness in
> responding to this blocker, not that we have no remedy.
>
> We should probably take John Bush's insight to heart, that we should
> be looking for better solutions longer term. But dropping these for
> 2.7 seems to me precipitous at this stage of the release cycle.
>
>  

The MT recommendation was made in support of Alan's recommendation on
the 10th, that in turn was based on Noah's submission (as I understand
it) that the OSP team was unable to support these tools.


Regards

David


_______________________________________________
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: MT deprecation recommendations for 2.7

That may be the case, but I checked with Noah and Chris on Friday -
while the larger thread was still unspooling - and I've reported what
they told me then. If I misunderstood, happy to hear it.

~Clay

On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]> wrote:

> Hi Clay
>
> One point of clarity bellow
>>> 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.
>>>
>> This looks to me hasty. The fact that it is outside the MT's capacity
>> to maintain does not strike me as a decisive argument. It comes a
>> little too close to asking the code to conform to the shape of the MT
>> rather than the other way around, and it might be a better answer to
>> recruit broader expertise for the MT. I don't think it's imagined that
>> all maintenance would be completed by the maintenance team, especially
>> during these formative stages of its growth.
>>
>> Now, if the MT can't maintain it *and* there is no other community
>> resource that can help, that's a stronger case. But as I understand it
>> the blocker issues for Reports are going to be examined by Noah, who
>> thinks it might be corrected by backing out some earlier work, while
>> we've heard that IU uses Reports in production.  My impression is that
>> the apparent lack of community support is a matter of slowness in
>> responding to this blocker, not that we have no remedy.
>>
>> We should probably take John Bush's insight to heart, that we should
>> be looking for better solutions longer term. But dropping these for
>> 2.7 seems to me precipitous at this stage of the release cycle.
>>
>>
>
> The MT recommendation was made in support of Alan's recommendation on
> the 10th, that in turn was based on Noah's submission (as I understand
> it) that the OSP team was unable to support these tools.
>
>
> Regards
>
> David
>
>
> _______________________________________________
> 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"
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

I made a change to address a static code review finding. Things were  
broken afterwards. I reverted that change and do not plan to try  
again to address the static analysis concern.

I am, for my part, done with reports for 2.7 and concur with the  
recommendation to move to contrib. To speak plainly, I see it as a  
functional trap that suggests desirable functionality but leads to  
much wandering and confusion. Michigan does not plan to support the  
tool. Others might, but I still recommend it live in contrib. I thank  
John for his honest appraisal.

The functional and technical investment requirements for usage  
warrant, to me, an opt-in strategy (contrib installation). Consider  
it "advanced mode" where this is the first "skill test" of many.

I, personally, cannot speak to the tools' status, whether functioning  
as intended or not. I do not use them and do not know the code. They  
are as they were, as far as the code is concerned.

Thanks,
-Noah

On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:

> That may be the case, but I checked with Noah and Chris on Friday -
> while the larger thread was still unspooling - and I've reported what
> they told me then. If I misunderstood, happy to hear it.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz  
> <[hidden email]> wrote:
>> Hi Clay
>>
>> One point of clarity bellow
>>>> 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.
>>>>
>>> This looks to me hasty. The fact that it is outside the MT's  
>>> capacity
>>> to maintain does not strike me as a decisive argument. It comes a
>>> little too close to asking the code to conform to the shape of  
>>> the MT
>>> rather than the other way around, and it might be a better answer to
>>> recruit broader expertise for the MT. I don't think it's imagined  
>>> that
>>> all maintenance would be completed by the maintenance team,  
>>> especially
>>> during these formative stages of its growth.
>>>
>>> Now, if the MT can't maintain it *and* there is no other community
>>> resource that can help, that's a stronger case. But as I  
>>> understand it
>>> the blocker issues for Reports are going to be examined by Noah, who
>>> thinks it might be corrected by backing out some earlier work, while
>>> we've heard that IU uses Reports in production.  My impression is  
>>> that
>>> the apparent lack of community support is a matter of slowness in
>>> responding to this blocker, not that we have no remedy.
>>>
>>> We should probably take John Bush's insight to heart, that we should
>>> be looking for better solutions longer term. But dropping these for
>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>
>>>
>>
>> The MT recommendation was made in support of Alan's recommendation on
>> the 10th, that in turn was based on Noah's submission (as I  
>> understand
>> it) that the OSP team was unable to support these tools.
>>
>>
>> Regards
>>
>> David
>>
>>
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to management-
>> [hidden email] with a subject of "unsubscribe"
>>
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-
> [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: MT deprecation recommendations for 2.7

Thanks for the clarification, Noah.

It still, however, leaves us in a situation where we've heard from two
institutions that use Reports in production (IU and RI), and there may
be others we haven't heard from. I think we need to assume so, nor can
we assume that all such institutions are able to work with the source.

~Clay

On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:

> I made a change to address a static code review finding. Things were broken
> afterwards. I reverted that change and do not plan to try again to address
> the static analysis concern.
>
> I am, for my part, done with reports for 2.7 and concur with the
> recommendation to move to contrib. To speak plainly, I see it as a
> functional trap that suggests desirable functionality but leads to much
> wandering and confusion. Michigan does not plan to support the tool. Others
> might, but I still recommend it live in contrib. I thank John for his honest
> appraisal.
>
> The functional and technical investment requirements for usage warrant, to
> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
> where this is the first "skill test" of many.
>
> I, personally, cannot speak to the tools' status, whether functioning as
> intended or not. I do not use them and do not know the code. They are as
> they were, as far as the code is concerned.
>
> Thanks,
> -Noah
>
> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>
>> That may be the case, but I checked with Noah and Chris on Friday -
>> while the larger thread was still unspooling - and I've reported what
>> they told me then. If I misunderstood, happy to hear it.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>> wrote:
>>>
>>> Hi Clay
>>>
>>> One point of clarity bellow
>>>>>
>>>>> 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.
>>>>>
>>>> This looks to me hasty. The fact that it is outside the MT's capacity
>>>> to maintain does not strike me as a decisive argument. It comes a
>>>> little too close to asking the code to conform to the shape of the MT
>>>> rather than the other way around, and it might be a better answer to
>>>> recruit broader expertise for the MT. I don't think it's imagined that
>>>> all maintenance would be completed by the maintenance team, especially
>>>> during these formative stages of its growth.
>>>>
>>>> Now, if the MT can't maintain it *and* there is no other community
>>>> resource that can help, that's a stronger case. But as I understand it
>>>> the blocker issues for Reports are going to be examined by Noah, who
>>>> thinks it might be corrected by backing out some earlier work, while
>>>> we've heard that IU uses Reports in production.  My impression is that
>>>> the apparent lack of community support is a matter of slowness in
>>>> responding to this blocker, not that we have no remedy.
>>>>
>>>> We should probably take John Bush's insight to heart, that we should
>>>> be looking for better solutions longer term. But dropping these for
>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>
>>>>
>>>
>>> The MT recommendation was made in support of Alan's recommendation on
>>> the 10th, that in turn was based on Noah's submission (as I understand
>>> it) that the OSP team was unable to support these tools.
>>>
>>>
>>> Regards
>>>
>>> David
>>>
>>>
>>> _______________________________________________
>>> 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"
David Horwitz David Horwitz
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

On the flip side we are including code in the source that a) is not
maintained b) is effectively un-qa'ed as we seem to have no way to test
if it works as advertised.

At the very minimum I think those who know how this functionality works
need to write a test plan for it.

(personal rather than MT view :-)
D

On 03/14/2010 09:48 PM, Clay Fenlason wrote:

> Thanks for the clarification, Noah.
>
> It still, however, leaves us in a situation where we've heard from two
> institutions that use Reports in production (IU and RI), and there may
> be others we haven't heard from. I think we need to assume so, nor can
> we assume that all such institutions are able to work with the source.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
>  
>> I made a change to address a static code review finding. Things were broken
>> afterwards. I reverted that change and do not plan to try again to address
>> the static analysis concern.
>>
>> I am, for my part, done with reports for 2.7 and concur with the
>> recommendation to move to contrib. To speak plainly, I see it as a
>> functional trap that suggests desirable functionality but leads to much
>> wandering and confusion. Michigan does not plan to support the tool. Others
>> might, but I still recommend it live in contrib. I thank John for his honest
>> appraisal.
>>
>> The functional and technical investment requirements for usage warrant, to
>> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>> where this is the first "skill test" of many.
>>
>> I, personally, cannot speak to the tools' status, whether functioning as
>> intended or not. I do not use them and do not know the code. They are as
>> they were, as far as the code is concerned.
>>
>> Thanks,
>> -Noah
>>
>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>
>>    
>>> That may be the case, but I checked with Noah and Chris on Friday -
>>> while the larger thread was still unspooling - and I've reported what
>>> they told me then. If I misunderstood, happy to hear it.
>>>
>>> ~Clay
>>>
>>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>>> wrote:
>>>      
>>>> Hi Clay
>>>>
>>>> One point of clarity bellow
>>>>        
>>>>>> 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.
>>>>>>
>>>>>>            
>>>>> This looks to me hasty. The fact that it is outside the MT's capacity
>>>>> to maintain does not strike me as a decisive argument. It comes a
>>>>> little too close to asking the code to conform to the shape of the MT
>>>>> rather than the other way around, and it might be a better answer to
>>>>> recruit broader expertise for the MT. I don't think it's imagined that
>>>>> all maintenance would be completed by the maintenance team, especially
>>>>> during these formative stages of its growth.
>>>>>
>>>>> Now, if the MT can't maintain it *and* there is no other community
>>>>> resource that can help, that's a stronger case. But as I understand it
>>>>> the blocker issues for Reports are going to be examined by Noah, who
>>>>> thinks it might be corrected by backing out some earlier work, while
>>>>> we've heard that IU uses Reports in production.  My impression is that
>>>>> the apparent lack of community support is a matter of slowness in
>>>>> responding to this blocker, not that we have no remedy.
>>>>>
>>>>> We should probably take John Bush's insight to heart, that we should
>>>>> be looking for better solutions longer term. But dropping these for
>>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>>
>>>>>
>>>>>          
>>>> The MT recommendation was made in support of Alan's recommendation on
>>>> the 10th, that in turn was based on Noah's submission (as I understand
>>>> it) that the OSP team was unable to support these tools.
>>>>
>>>>
>>>> Regards
>>>>
>>>> David
>>>>
>>>>
>>>> _______________________________________________
>>>> 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"
Noah Botimer Noah Botimer
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

Sure. Mine is just an opinion that weighs the "shiny object" factor  
against the "bear trap" factor and the "sysadmin ninja" factor.

That is, the technology bar is already very high with reports. It may  
be reasonable in this case, where it may not in others, to put a  
protective seal (explicit installation) on these tools to help  
protect innocent explorers from their curiosity.

A test plan would be great but I would hazard a guess that it will  
not be forthcoming as we have tried to rally these resources already  
on this cycle. I'd be delighted to find otherwise, but also cannot  
commit myself.

I won't pretend to make a binding decision here. Only offer a  
perspective.

Thanks,
-Noah

On Mar 14, 2010, at 4:03 PM, David Horwitz wrote:

> On the flip side we are including code in the source that a) is not
> maintained b) is effectively un-qa'ed as we seem to have no way to  
> test
> if it works as advertised.
>
> At the very minimum I think those who know how this functionality  
> works
> need to write a test plan for it.
>
> (personal rather than MT view :-)
> D
>
> On 03/14/2010 09:48 PM, Clay Fenlason wrote:
>> Thanks for the clarification, Noah.
>>
>> It still, however, leaves us in a situation where we've heard from  
>> two
>> institutions that use Reports in production (IU and RI), and there  
>> may
>> be others we haven't heard from. I think we need to assume so, nor  
>> can
>> we assume that all such institutions are able to work with the  
>> source.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]>  
>> wrote:
>>
>>> I made a change to address a static code review finding. Things  
>>> were broken
>>> afterwards. I reverted that change and do not plan to try again  
>>> to address
>>> the static analysis concern.
>>>
>>> I am, for my part, done with reports for 2.7 and concur with the
>>> recommendation to move to contrib. To speak plainly, I see it as a
>>> functional trap that suggests desirable functionality but leads  
>>> to much
>>> wandering and confusion. Michigan does not plan to support the  
>>> tool. Others
>>> might, but I still recommend it live in contrib. I thank John for  
>>> his honest
>>> appraisal.
>>>
>>> The functional and technical investment requirements for usage  
>>> warrant, to
>>> me, an opt-in strategy (contrib installation). Consider it  
>>> "advanced mode"
>>> where this is the first "skill test" of many.
>>>
>>> I, personally, cannot speak to the tools' status, whether  
>>> functioning as
>>> intended or not. I do not use them and do not know the code. They  
>>> are as
>>> they were, as far as the code is concerned.
>>>
>>> Thanks,
>>> -Noah
>>>
>>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>>
>>>
>>>> That may be the case, but I checked with Noah and Chris on Friday -
>>>> while the larger thread was still unspooling - and I've reported  
>>>> what
>>>> they told me then. If I misunderstood, happy to hear it.
>>>>
>>>> ~Clay
>>>>
>>>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz  
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Clay
>>>>>
>>>>> One point of clarity bellow
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>> This looks to me hasty. The fact that it is outside the MT's  
>>>>>> capacity
>>>>>> to maintain does not strike me as a decisive argument. It comes a
>>>>>> little too close to asking the code to conform to the shape of  
>>>>>> the MT
>>>>>> rather than the other way around, and it might be a better  
>>>>>> answer to
>>>>>> recruit broader expertise for the MT. I don't think it's  
>>>>>> imagined that
>>>>>> all maintenance would be completed by the maintenance team,  
>>>>>> especially
>>>>>> during these formative stages of its growth.
>>>>>>
>>>>>> Now, if the MT can't maintain it *and* there is no other  
>>>>>> community
>>>>>> resource that can help, that's a stronger case. But as I  
>>>>>> understand it
>>>>>> the blocker issues for Reports are going to be examined by  
>>>>>> Noah, who
>>>>>> thinks it might be corrected by backing out some earlier work,  
>>>>>> while
>>>>>> we've heard that IU uses Reports in production.  My impression  
>>>>>> is that
>>>>>> the apparent lack of community support is a matter of slowness in
>>>>>> responding to this blocker, not that we have no remedy.
>>>>>>
>>>>>> We should probably take John Bush's insight to heart, that we  
>>>>>> should
>>>>>> be looking for better solutions longer term. But dropping  
>>>>>> these for
>>>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>>>
>>>>>>
>>>>>>
>>>>> The MT recommendation was made in support of Alan's  
>>>>> recommendation on
>>>>> the 10th, that in turn was based on Noah's submission (as I  
>>>>> understand
>>>>> it) that the OSP team was unable to support these tools.
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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"
Berg, Alan Berg, Alan
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

RE: [Management] MT deprecation recommendations for 2.7

Hi all,

The reports tools have failed Quality Assurance (no ability to test, unmaintainable by the MT, did not run on QA servers for a month).

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg




-----Original Message-----
From: [hidden email] on behalf of Noah Botimer
Sent: Sun 3/14/2010 21:34
To: David Horwitz
Cc: [hidden email]
Subject: Re: [Management] MT deprecation recommendations for 2.7

Sure. Mine is just an opinion that weighs the "shiny object" factor 
against the "bear trap" factor and the "sysadmin ninja" factor.

That is, the technology bar is already very high with reports. It may 
be reasonable in this case, where it may not in others, to put a 
protective seal (explicit installation) on these tools to help 
protect innocent explorers from their curiosity.

A test plan would be great but I would hazard a guess that it will 
not be forthcoming as we have tried to rally these resources already 
on this cycle. I'd be delighted to find otherwise, but also cannot 
commit myself.

I won't pretend to make a binding decision here. Only offer a 
perspective.

Thanks,
-Noah

On Mar 14, 2010, at 4:03 PM, David Horwitz wrote:

> On the flip side we are including code in the source that a) is not
> maintained b) is effectively un-qa'ed as we seem to have no way to 
> test
> if it works as advertised.
>
> At the very minimum I think those who know how this functionality 
> works
> need to write a test plan for it.
>
> (personal rather than MT view :-)
> D
>
> On 03/14/2010 09:48 PM, Clay Fenlason wrote:
>> Thanks for the clarification, Noah.
>>
>> It still, however, leaves us in a situation where we've heard from 
>> two
>> institutions that use Reports in production (IU and RI), and there 
>> may
>> be others we haven't heard from. I think we need to assume so, nor 
>> can
>> we assume that all such institutions are able to work with the 
>> source.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]
>> wrote:
>>
>>> I made a change to address a static code review finding. Things 
>>> were broken
>>> afterwards. I reverted that change and do not plan to try again 
>>> to address
>>> the static analysis concern.
>>>
>>> I am, for my part, done with reports for 2.7 and concur with the
>>> recommendation to move to contrib. To speak plainly, I see it as a
>>> functional trap that suggests desirable functionality but leads 
>>> to much
>>> wandering and confusion. Michigan does not plan to support the 
>>> tool. Others
>>> might, but I still recommend it live in contrib. I thank John for 
>>> his honest
>>> appraisal.
>>>
>>> The functional and technical investment requirements for usage 
>>> warrant, to
>>> me, an opt-in strategy (contrib installation). Consider it 
>>> "advanced mode"
>>> where this is the first "skill test" of many.
>>>
>>> I, personally, cannot speak to the tools' status, whether 
>>> functioning as
>>> intended or not. I do not use them and do not know the code. They 
>>> are as
>>> they were, as far as the code is concerned.
>>>
>>> Thanks,
>>> -Noah
>>>
>>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>>
>>>
>>>> That may be the case, but I checked with Noah and Chris on Friday -
>>>> while the larger thread was still unspooling - and I've reported 
>>>> what
>>>> they told me then. If I misunderstood, happy to hear it.
>>>>
>>>> ~Clay
>>>>
>>>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz 
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Clay
>>>>>
>>>>> One point of clarity bellow
>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>> This looks to me hasty. The fact that it is outside the MT's 
>>>>>> capacity
>>>>>> to maintain does not strike me as a decisive argument. It comes a
>>>>>> little too close to asking the code to conform to the shape of 
>>>>>> the MT
>>>>>> rather than the other way around, and it might be a better 
>>>>>> answer to
>>>>>> recruit broader expertise for the MT. I don't think it's 
>>>>>> imagined that
>>>>>> all maintenance would be completed by the maintenance team, 
>>>>>> especially
>>>>>> during these formative stages of its growth.
>>>>>>
>>>>>> Now, if the MT can't maintain it *and* there is no other 
>>>>>> community
>>>>>> resource that can help, that's a stronger case. But as I 
>>>>>> understand it
>>>>>> the blocker issues for Reports are going to be examined by 
>>>>>> Noah, who
>>>>>> thinks it might be corrected by backing out some earlier work, 
>>>>>> while
>>>>>> we've heard that IU uses Reports in production.  My impression 
>>>>>> is that
>>>>>> the apparent lack of community support is a matter of slowness in
>>>>>> responding to this blocker, not that we have no remedy.
>>>>>>
>>>>>> We should probably take John Bush's insight to heart, that we 
>>>>>> should
>>>>>> be looking for better solutions longer term. But dropping 
>>>>>> these for
>>>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>>>
>>>>>>
>>>>>>
>>>>> The MT recommendation was made in support of Alan's 
>>>>> recommendation on
>>>>> the 10th, that in turn was based on Noah's submission (as I 
>>>>> understand
>>>>> it) that the OSP team was unable to support these tools.
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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"


_______________________________________________
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: MT deprecation recommendations for 2.7

In reply to this post by Clay Fenlason
In an earlier email I provided clarification regarding the MT's list of 2.7 deprecation recommendations and I have seen no compelling arguments that suggest we should undertake a different course of action with respect to mailtool, presentation, reports, warehouse and blog.   So I plan to do the following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22 March 2010.

Deprecated as of 2.6.0, remove from 2.7.0
1. Mailtool: remove the project from svn .externals and eliminate it from the tag.  When convenient we migrate mailtool to contrib and eliminate it from trunk/2.7.x.
2. Presentation: remove the project from svn .externals and eliminate it from the tag.  When convenient we migrate presentation to contrib and eliminate it from trunk/2.7.x.

Unsupported trunk/2.7.x code
1. Stealth reports
2. Stealth warehouse
3. Stealth blog

When I get back to the US I will start work on the 2.7.0 install guide and release notes.  The release notes will list blog, reports and warehouse as deprecrated and targeted for removal in the next Sakai 2.x minor release (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override; an option that in my view does not impose an undue burden on school's that want/need to run blog, reports and warehouse in 2.7.

If one or more institutions wish to step forward and provide active support for either reports (e.g., IU for instance), warehouse or blog we should consider unstealthing the tool either for 2.7.0 (if immediate support is available) or perhaps for 2.7.1 (allowing the team some ramp up time).  Schools can take over the tool by forming a conventional team (e.g. like the msgcntr or samigo teams) or contribute one or more resources to the maintenance team that can focus on it (as has occurred recently when I invited David Roldan Martinez to join the maintenance team to work on i18n issues). 

We should be firm when it comes to unsupported/abandoned tool code in core Sakai: the tool gets marked as deprecated and stealthed in sakai.properties for the upcoming release.  A community alert regarding the change in status should be issued and institutions with a stake in a deprecated tool should be invited to step forward to help maintain it.  If no one steps forward the tool is targeted for removal in the next minor release.

We generate releases for the benefit of the entire community not single institutions.  Given this we should be wary of permitting unsupported/abandoned code to exist in production releases because one institution or another may be inconvenienced by either stealthing or removal.  

If anyone objects to the plan outlined above regarding the next QA tag please reply on list.

Cheers,

Anth


Begin forwarded message:

From: Anthony Whyte <[hidden email]>
Date: March 13, 2010 1:50:23 AM GMT+02:00
To: Clay Fenlason <[hidden email]>
Subject: Re: [Building Sakai] [Management] 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/


On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:

Thanks for the clarification, Noah.

It still, however, leaves us in a situation where we've heard from two
institutions that use Reports in production (IU and RI), and there may
be others we haven't heard from. I think we need to assume so, nor can
we assume that all such institutions are able to work with the source.

~Clay

On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
I made a change to address a static code review finding. Things were broken
afterwards. I reverted that change and do not plan to try again to address
the static analysis concern.

I am, for my part, done with reports for 2.7 and concur with the
recommendation to move to contrib. To speak plainly, I see it as a
functional trap that suggests desirable functionality but leads to much
wandering and confusion. Michigan does not plan to support the tool. Others
might, but I still recommend it live in contrib. I thank John for his honest
appraisal.

The functional and technical investment requirements for usage warrant, to
me, an opt-in strategy (contrib installation). Consider it "advanced mode"
where this is the first "skill test" of many.

I, personally, cannot speak to the tools' status, whether functioning as
intended or not. I do not use them and do not know the code. They are as
they were, as far as the code is concerned.

Thanks,
-Noah

On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:

That may be the case, but I checked with Noah and Chris on Friday -
while the larger thread was still unspooling - and I've reported what
they told me then. If I misunderstood, happy to hear it.

~Clay

On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
wrote:

Hi Clay

One point of clarity bellow

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.

This looks to me hasty. The fact that it is outside the MT's capacity
to maintain does not strike me as a decisive argument. It comes a
little too close to asking the code to conform to the shape of the MT
rather than the other way around, and it might be a better answer to
recruit broader expertise for the MT. I don't think it's imagined that
all maintenance would be completed by the maintenance team, especially
during these formative stages of its growth.

Now, if the MT can't maintain it *and* there is no other community
resource that can help, that's a stronger case. But as I understand it
the blocker issues for Reports are going to be examined by Noah, who
thinks it might be corrected by backing out some earlier work, while
we've heard that IU uses Reports in production.  My impression is that
the apparent lack of community support is a matter of slowness in
responding to this blocker, not that we have no remedy.

We should probably take John Bush's insight to heart, that we should
be looking for better solutions longer term. But dropping these for
2.7 seems to me precipitous at this stage of the release cycle.



The MT recommendation was made in support of Alan's recommendation on
the 10th, that in turn was based on Noah's submission (as I understand
it) that the OSP team was unable to support these tools.


Regards

David


_______________________________________________
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"




_______________________________________________
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
David Horwitz David Horwitz
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

In reply to this post by Berg, Alan
Hi Alan,

Maybe you could outline what would be required for the tool to meet QA,
assuming that they are stealthed and marked for deprecation?

regards

David

On 03/14/2010 11:37 PM, Berg, Alan wrote:

> Hi all,
>
> The reports tools have failed Quality Assurance (no ability to test, unmaintainable by the MT, did not run on QA servers for a month).
>
> Alan
>
> Alan Berg
> Interim QA Director - The Sakai Foundation
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
> http://home.uva.nl/a.m.berg
>
>
>
>
> -----Original Message-----
> From: [hidden email] on behalf of Noah Botimer
> Sent: Sun 3/14/2010 21:34
> To: David Horwitz
> Cc: [hidden email]
> Subject: Re: [Management] MT deprecation recommendations for 2.7
>  
> Sure. Mine is just an opinion that weighs the "shiny object" factor  
> against the "bear trap" factor and the "sysadmin ninja" factor.
>
> That is, the technology bar is already very high with reports. It may  
> be reasonable in this case, where it may not in others, to put a  
> protective seal (explicit installation) on these tools to help  
> protect innocent explorers from their curiosity.
>
> A test plan would be great but I would hazard a guess that it will  
> not be forthcoming as we have tried to rally these resources already  
> on this cycle. I'd be delighted to find otherwise, but also cannot  
> commit myself.
>
> I won't pretend to make a binding decision here. Only offer a  
> perspective.
>
> Thanks,
> -Noah
>
> On Mar 14, 2010, at 4:03 PM, David Horwitz wrote:
>
>  
>> On the flip side we are including code in the source that a) is not
>> maintained b) is effectively un-qa'ed as we seem to have no way to  
>> test
>> if it works as advertised.
>>
>> At the very minimum I think those who know how this functionality  
>> works
>> need to write a test plan for it.
>>
>> (personal rather than MT view :-)
>> D
>>
>> On 03/14/2010 09:48 PM, Clay Fenlason wrote:
>>    
>>> Thanks for the clarification, Noah.
>>>
>>> It still, however, leaves us in a situation where we've heard from  
>>> two
>>> institutions that use Reports in production (IU and RI), and there  
>>> may
>>> be others we haven't heard from. I think we need to assume so, nor  
>>> can
>>> we assume that all such institutions are able to work with the  
>>> source.
>>>
>>> ~Clay
>>>
>>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]>  
>>> wrote:
>>>
>>>      
>>>> I made a change to address a static code review finding. Things  
>>>> were broken
>>>> afterwards. I reverted that change and do not plan to try again  
>>>> to address
>>>> the static analysis concern.
>>>>
>>>> I am, for my part, done with reports for 2.7 and concur with the
>>>> recommendation to move to contrib. To speak plainly, I see it as a
>>>> functional trap that suggests desirable functionality but leads  
>>>> to much
>>>> wandering and confusion. Michigan does not plan to support the  
>>>> tool. Others
>>>> might, but I still recommend it live in contrib. I thank John for  
>>>> his honest
>>>> appraisal.
>>>>
>>>> The functional and technical investment requirements for usage  
>>>> warrant, to
>>>> me, an opt-in strategy (contrib installation). Consider it  
>>>> "advanced mode"
>>>> where this is the first "skill test" of many.
>>>>
>>>> I, personally, cannot speak to the tools' status, whether  
>>>> functioning as
>>>> intended or not. I do not use them and do not know the code. They  
>>>> are as
>>>> they were, as far as the code is concerned.
>>>>
>>>> Thanks,
>>>> -Noah
>>>>
>>>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>>>
>>>>
>>>>        
>>>>> That may be the case, but I checked with Noah and Chris on Friday -
>>>>> while the larger thread was still unspooling - and I've reported  
>>>>> what
>>>>> they told me then. If I misunderstood, happy to hear it.
>>>>>
>>>>> ~Clay
>>>>>
>>>>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz  
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>          
>>>>>> Hi Clay
>>>>>>
>>>>>> One point of clarity bellow
>>>>>>
>>>>>>            
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>                
>>>>>>> This looks to me hasty. The fact that it is outside the MT's  
>>>>>>> capacity
>>>>>>> to maintain does not strike me as a decisive argument. It comes a
>>>>>>> little too close to asking the code to conform to the shape of  
>>>>>>> the MT
>>>>>>> rather than the other way around, and it might be a better  
>>>>>>> answer to
>>>>>>> recruit broader expertise for the MT. I don't think it's  
>>>>>>> imagined that
>>>>>>> all maintenance would be completed by the maintenance team,  
>>>>>>> especially
>>>>>>> during these formative stages of its growth.
>>>>>>>
>>>>>>> Now, if the MT can't maintain it *and* there is no other  
>>>>>>> community
>>>>>>> resource that can help, that's a stronger case. But as I  
>>>>>>> understand it
>>>>>>> the blocker issues for Reports are going to be examined by  
>>>>>>> Noah, who
>>>>>>> thinks it might be corrected by backing out some earlier work,  
>>>>>>> while
>>>>>>> we've heard that IU uses Reports in production.  My impression  
>>>>>>> is that
>>>>>>> the apparent lack of community support is a matter of slowness in
>>>>>>> responding to this blocker, not that we have no remedy.
>>>>>>>
>>>>>>> We should probably take John Bush's insight to heart, that we  
>>>>>>> should
>>>>>>> be looking for better solutions longer term. But dropping  
>>>>>>> these for
>>>>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>> The MT recommendation was made in support of Alan's  
>>>>>> recommendation on
>>>>>> the 10th, that in turn was based on Noah's submission (as I  
>>>>>> understand
>>>>>> it) that the OSP team was unable to support these tools.
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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"
>
>
>  
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Berg, Alan Berg, Alan
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

In reply to this post by Anthony Whyte
RE: [Management] MT deprecation recommendations for 2.7

+1

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg


+1


-----Original Message-----
From: [hidden email] on behalf of Anthony Whyte
Sent: Mon 3/15/2010 0:40
To: Clay Fenlason
Cc: [hidden email]; Sakai QA; Developers Sakai-Dev
Subject: Re: [Management] MT deprecation recommendations for 2.7

In an earlier email I provided clarification regarding the MT's list of 2.7 deprecation recommendations and I have seen no compelling arguments that suggest we should undertake a different course of action with respect to mailtool, presentation, reports, warehouse and blog.   So I plan to do the following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22 March 2010.

Deprecated as of 2.6.0, remove from 2.7.0
1. Mailtool: remove the project from svn .externals and eliminate it from the tag.  When convenient we migrate mailtool to contrib and eliminate it from trunk/2.7.x.
2. Presentation: remove the project from svn .externals and eliminate it from the tag.  When convenient we migrate presentation to contrib and eliminate it from trunk/2.7.x.

Unsupported trunk/2.7.x code
1. Stealth reports
2. Stealth warehouse
3. Stealth blog

When I get back to the US I will start work on the 2.7.0 install guide and release notes.  The release notes will list blog, reports and warehouse as deprecrated and targeted for removal in the next Sakai 2.x minor release (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override; an option that in my view does not impose an undue burden on school's that want/need to run blog, reports and warehouse in 2.7.

If one or more institutions wish to step forward and provide active support for either reports (e.g., IU for instance), warehouse or blog we should consider unstealthing the tool either for 2.7.0 (if immediate support is available) or perhaps for 2.7.1 (allowing the team some ramp up time).  Schools can take over the tool by forming a conventional team (e.g. like the msgcntr or samigo teams) or contribute one or more resources to the maintenance team that can focus on it (as has occurred recently when I invited David Roldan Martinez to join the maintenance team to work on i18n issues).

We should be firm when it comes to unsupported/abandoned tool code in core Sakai: the tool gets marked as deprecated and stealthed in sakai.properties for the upcoming release.  A community alert regarding the change in status should be issued and institutions with a stake in a deprecated tool should be invited to step forward to help maintain it.  If no one steps forward the tool is targeted for removal in the next minor release.

We generate releases for the benefit of the entire community not single institutions.  Given this we should be wary of permitting unsupported/abandoned code to exist in production releases because one institution or another may be inconvenienced by either stealthing or removal. 

If anyone objects to the plan outlined above regarding the next QA tag please reply on list.

Cheers,

Anth


Begin forwarded message:

> From: Anthony Whyte <[hidden email]>
> Date: March 13, 2010 1:50:23 AM GMT+02:00
> To: Clay Fenlason <[hidden email]>
> Cc: "May, Megan Marie" <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email] Developers" <[hidden email]>
> Subject: Re: [Building Sakai] [Management] 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/



On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:

> Thanks for the clarification, Noah.
>
> It still, however, leaves us in a situation where we've heard from two
> institutions that use Reports in production (IU and RI), and there may
> be others we haven't heard from. I think we need to assume so, nor can
> we assume that all such institutions are able to work with the source.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
>> I made a change to address a static code review finding. Things were broken
>> afterwards. I reverted that change and do not plan to try again to address
>> the static analysis concern.
>>
>> I am, for my part, done with reports for 2.7 and concur with the
>> recommendation to move to contrib. To speak plainly, I see it as a
>> functional trap that suggests desirable functionality but leads to much
>> wandering and confusion. Michigan does not plan to support the tool. Others
>> might, but I still recommend it live in contrib. I thank John for his honest
>> appraisal.
>>
>> The functional and technical investment requirements for usage warrant, to
>> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>> where this is the first "skill test" of many.
>>
>> I, personally, cannot speak to the tools' status, whether functioning as
>> intended or not. I do not use them and do not know the code. They are as
>> they were, as far as the code is concerned.
>>
>> Thanks,
>> -Noah
>>
>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>
>>> That may be the case, but I checked with Noah and Chris on Friday -
>>> while the larger thread was still unspooling - and I've reported what
>>> they told me then. If I misunderstood, happy to hear it.
>>>
>>> ~Clay
>>>
>>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>>> wrote:
>>>>
>>>> Hi Clay
>>>>
>>>> One point of clarity bellow
>>>>>>
>>>>>> 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.
>>>>>>
>>>>> This looks to me hasty. The fact that it is outside the MT's capacity
>>>>> to maintain does not strike me as a decisive argument. It comes a
>>>>> little too close to asking the code to conform to the shape of the MT
>>>>> rather than the other way around, and it might be a better answer to
>>>>> recruit broader expertise for the MT. I don't think it's imagined that
>>>>> all maintenance would be completed by the maintenance team, especially
>>>>> during these formative stages of its growth.
>>>>>
>>>>> Now, if the MT can't maintain it *and* there is no other community
>>>>> resource that can help, that's a stronger case. But as I understand it
>>>>> the blocker issues for Reports are going to be examined by Noah, who
>>>>> thinks it might be corrected by backing out some earlier work, while
>>>>> we've heard that IU uses Reports in production.  My impression is that
>>>>> the apparent lack of community support is a matter of slowness in
>>>>> responding to this blocker, not that we have no remedy.
>>>>>
>>>>> We should probably take John Bush's insight to heart, that we should
>>>>> be looking for better solutions longer term. But dropping these for
>>>>> 2.7 seems to me precipitous at this stage of the release cycle.
>>>>>
>>>>>
>>>>
>>>> The MT recommendation was made in support of Alan's recommendation on
>>>> the 10th, that in turn was based on Noah's submission (as I understand
>>>> it) that the OSP team was unable to support these tools.
>>>>
>>>>
>>>> Regards
>>>>
>>>> David
>>>>
>>>>
>>>> _______________________________________________
>>>> 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"
>
>



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

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Stephen Marquard Stephen Marquard
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

In reply to this post by Berg, Alan
Alan,

If You say "XYZ failed QA" without a community-agreed definition of what it means to pass or fail and what consequences it has, it risks being understood as just "Alan has a low opinion of XYZ".

QA in Sakai has historically been a best-effort, continuous improvement process. While there are good reasons to change aspects of that, IMO to do so will take more consensus than an ad-hoc definition such as the one below. If I'm missing some Confluence page with pass/fail definitions for QA processes and how this affects the release management process, please point me to it.

Regards
Stephen

>>> "Berg, Alan" <[hidden email]> 3/14/2010 11:37 PM >>>
Hi all,

The reports tools have failed Quality Assurance (no ability to test, unmaintainable by the MT, did not run on QA servers for a month).

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg 



_______________________________________________
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: MT deprecation recommendations for 2.7

In reply to this post by Anthony Whyte
Anthony:

Sorry that your earlier note slipped past me, and that I then retrod
much of the same ground.

What you've proposed sounds consistent to me with our informal
deprecation policy and the comments others have made on list recently.

With perhaps one exception. It's not clear to me what the consensus is
on the JCR service. Stephen questioned its removal (presumably to
contrib) given that at least one known tool makes use of it. Ian then
confirmed that Cambridge also has it running in production. Ian has
said it's ok with him to move it into contrib, but I take that in the
same spirit in which it's ok with Noah if OSP tools go into contrib -
they're both comfortable making the code do what they want it to, and
we need to also be concerned with others who can't adapt as quickly.

But given the range of options available (eg. leave it in trunk or a
source checkout, but not a release binary, etc.) it's not clear to me
what the right balance is to strike with the JCR Service, apart from
the fact that it seems best not to move it to contrib straight away.
I'm not proposing a particular solution, I just want to be clear on
where consensus opinion has come down, or at least get something
spelled out that makes people realize we need to hash it out some
more.

~Clay

On Sun, Mar 14, 2010 at 7:40 PM, Anthony Whyte <[hidden email]> wrote:

> In an earlier email I provided clarification regarding the MT's list of 2.7
> deprecation recommendations and I have seen no compelling arguments that
> suggest we should undertake a different course of action with respect to
> mailtool, presentation, reports, warehouse and blog.   So I plan to do the
> following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22
> March 2010.
> Deprecated as of 2.6.0, remove from 2.7.0
> 1. Mailtool: remove the project from svn .externals and eliminate it from
> the tag.  When convenient we migrate mailtool to contrib and eliminate it
> from trunk/2.7.x.
> 2. Presentation: remove the project from svn .externals and eliminate it
> from the tag.  When convenient we migrate presentation to contrib and
> eliminate it from trunk/2.7.x.
> Unsupported trunk/2.7.x code
> 1. Stealth reports
> 2. Stealth warehouse
> 3. Stealth blog
> When I get back to the US I will start work on the 2.7.0 install guide and
> release notes.  The release notes will list blog, reports and warehouse as
> deprecrated and targeted for removal in the next Sakai 2.x minor release
> (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override;
> an option that in my view does not impose an undue burden on school's that
> want/need to run blog, reports and warehouse in 2.7.
> If one or more institutions wish to step forward and provide active support
> for either reports (e.g., IU for instance), warehouse or blog we should
> consider unstealthing the tool either for 2.7.0 (if immediate support is
> available) or perhaps for 2.7.1 (allowing the team some ramp up time).
>  Schools can take over the tool by forming a conventional team (e.g. like
> the msgcntr or samigo teams) or contribute one or more resources to the
> maintenance team that can focus on it (as has occurred recently when I
> invited David Roldan Martinez to join the maintenance team to work on i18n
> issues).
> We should be firm when it comes to unsupported/abandoned tool code in core
> Sakai: the tool gets marked as deprecated and stealthed in sakai.properties
> for the upcoming release.  A community alert regarding the change in status
> should be issued and institutions with a stake in a deprecated tool should
> be invited to step forward to help maintain it.  If no one steps forward the
> tool is targeted for removal in the next minor release.
> We generate releases for the benefit of the entire community not single
> institutions.  Given this we should be wary of permitting
> unsupported/abandoned code to exist in production releases because one
> institution or another may be inconvenienced by either stealthing or
> removal.
> If anyone objects to the plan outlined above regarding the next QA tag
> please reply on list.
> Cheers,
> Anth
>
> Begin forwarded message:
>
> From: Anthony Whyte <[hidden email]>
> Date: March 13, 2010 1:50:23 AM GMT+02:00
> To: Clay Fenlason <[hidden email]>
> Cc: "May, Megan Marie" <[hidden email]>,
> "[hidden email]" <[hidden email]>,
> "[hidden email]" <[hidden email]>,
> "[hidden email] Developers"
> <[hidden email]>
> Subject: Re: [Building Sakai] [Management] 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/
>
> On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:
>
> Thanks for the clarification, Noah.
>
> It still, however, leaves us in a situation where we've heard from two
> institutions that use Reports in production (IU and RI), and there may
> be others we haven't heard from. I think we need to assume so, nor can
> we assume that all such institutions are able to work with the source.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
>
> I made a change to address a static code review finding. Things were broken
>
> afterwards. I reverted that change and do not plan to try again to address
>
> the static analysis concern.
>
> I am, for my part, done with reports for 2.7 and concur with the
>
> recommendation to move to contrib. To speak plainly, I see it as a
>
> functional trap that suggests desirable functionality but leads to much
>
> wandering and confusion. Michigan does not plan to support the tool. Others
>
> might, but I still recommend it live in contrib. I thank John for his honest
>
> appraisal.
>
> The functional and technical investment requirements for usage warrant, to
>
> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>
> where this is the first "skill test" of many.
>
> I, personally, cannot speak to the tools' status, whether functioning as
>
> intended or not. I do not use them and do not know the code. They are as
>
> they were, as far as the code is concerned.
>
> Thanks,
>
> -Noah
>
> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>
> That may be the case, but I checked with Noah and Chris on Friday -
>
> while the larger thread was still unspooling - and I've reported what
>
> they told me then. If I misunderstood, happy to hear it.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>
> wrote:
>
> Hi Clay
>
> One point of clarity bellow
>
> 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.
>
> This looks to me hasty. The fact that it is outside the MT's capacity
>
> to maintain does not strike me as a decisive argument. It comes a
>
> little too close to asking the code to conform to the shape of the MT
>
> rather than the other way around, and it might be a better answer to
>
> recruit broader expertise for the MT. I don't think it's imagined that
>
> all maintenance would be completed by the maintenance team, especially
>
> during these formative stages of its growth.
>
> Now, if the MT can't maintain it *and* there is no other community
>
> resource that can help, that's a stronger case. But as I understand it
>
> the blocker issues for Reports are going to be examined by Noah, who
>
> thinks it might be corrected by backing out some earlier work, while
>
> we've heard that IU uses Reports in production.  My impression is that
>
> the apparent lack of community support is a matter of slowness in
>
> responding to this blocker, not that we have no remedy.
>
> We should probably take John Bush's insight to heart, that we should
>
> be looking for better solutions longer term. But dropping these for
>
> 2.7 seems to me precipitous at this stage of the release cycle.
>
>
>
> The MT recommendation was made in support of Alan's recommendation on
>
> the 10th, that in turn was based on Noah's submission (as I understand
>
> it) that the OSP team was unable to support these tools.
>
>
> Regards
>
> David
>
>
> _______________________________________________
>
> 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"
>
>
>
>
_______________________________________________
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] MT deprecation recommendations for 2.7

Yes, I sidestepped both JCR as well as the static cover deprecations recommendations in my email of last Sunday, choosing instead to focus solely on 2.7 tool deprecations in an effort to secure at least lazy consensus on how I planned to handle deprecations in the next QA tag.

JCR
Despite the experimental nature of JCR I recommend we follow the same approach as we do for tool deprecations: deprecate in kernel-1.1 and remove in kernel-1.2 (moving JCR to contrib).  This should provide sufficient time for anyone using the JCR service to adjust their build practices to compensate for it's eventual removal from the kernel.  We should announce this decision with a deprecation alert (I plan to draft these when I return to the US) and provide one or more reminders of JCR's impending removal during 2010, early 2011.

COVERS
You've no doubt seen the objections raised regarding deprecating static covers in the kernel and elsewhere.  While I am not persuaded by the claims that static cover removal truly raises barriers to writing Sakai tools--is it really all that challenging to add a service injection setter method that relies on a bit of XML residing in a Spring bean configuration file?--I am sensitive to the assertion that static cover removal imposes costs on those maintaining local code that make use of the covers.  Indeed, for an example of the refactoring involved in removing static covers in favor of service injection see http://jira.sakaiproject.org/browse/SAK-12077.  The work, while by no means onerous or difficult, is nevertheless non-trivial.

Moreover, the kernel team is currently split on this issue in so far as static cover removal is concerned--a difference of opinion that raises something of a blocker to the removal proposal, although it should be recalled that static cover removal as proposed by David Horwitz would not commence for some time.

COMPROMISE PROPOSAL
I'd like to see static covers eventually removed (so +1) but recognize that the current crowd wisdom appears to consider this desire, well, unwise.  Still, I'd like to suggest a compromise proposal, one that permits the removal of a static cover whenever it impedes the implementation of unit tests written in support of a bug fix.  Extension of 2.x unit test coverage is work that meets a long standing yet largely unrealized goal of the Sakai Community.  Suspending such work because one finds a static cover in the way appears to me unwise.

Cheers,

Anth


On Mar 17, 2010, at 8:19 PM, Clay Fenlason wrote:

> Anthony:
>
> Sorry that your earlier note slipped past me, and that I then retrod
> much of the same ground.
>
> What you've proposed sounds consistent to me with our informal
> deprecation policy and the comments others have made on list recently.
>
> With perhaps one exception. It's not clear to me what the consensus is
> on the JCR service. Stephen questioned its removal (presumably to
> contrib) given that at least one known tool makes use of it. Ian then
> confirmed that Cambridge also has it running in production. Ian has
> said it's ok with him to move it into contrib, but I take that in the
> same spirit in which it's ok with Noah if OSP tools go into contrib -
> they're both comfortable making the code do what they want it to, and
> we need to also be concerned with others who can't adapt as quickly.
>
> But given the range of options available (eg. leave it in trunk or a
> source checkout, but not a release binary, etc.) it's not clear to me
> what the right balance is to strike with the JCR Service, apart from
> the fact that it seems best not to move it to contrib straight away.
> I'm not proposing a particular solution, I just want to be clear on
> where consensus opinion has come down, or at least get something
> spelled out that makes people realize we need to hash it out some
> more.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 7:40 PM, Anthony Whyte <[hidden email]> wrote:
>> In an earlier email I provided clarification regarding the MT's list of 2.7
>> deprecation recommendations and I have seen no compelling arguments that
>> suggest we should undertake a different course of action with respect to
>> mailtool, presentation, reports, warehouse and blog.   So I plan to do the
>> following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22
>> March 2010.
>> Deprecated as of 2.6.0, remove from 2.7.0
>> 1. Mailtool: remove the project from svn .externals and eliminate it from
>> the tag.  When convenient we migrate mailtool to contrib and eliminate it
>> from trunk/2.7.x.
>> 2. Presentation: remove the project from svn .externals and eliminate it
>> from the tag.  When convenient we migrate presentation to contrib and
>> eliminate it from trunk/2.7.x.
>> Unsupported trunk/2.7.x code
>> 1. Stealth reports
>> 2. Stealth warehouse
>> 3. Stealth blog
>> When I get back to the US I will start work on the 2.7.0 install guide and
>> release notes.  The release notes will list blog, reports and warehouse as
>> deprecrated and targeted for removal in the next Sakai 2.x minor release
>> (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override;
>> an option that in my view does not impose an undue burden on school's that
>> want/need to run blog, reports and warehouse in 2.7.
>> If one or more institutions wish to step forward and provide active support
>> for either reports (e.g., IU for instance), warehouse or blog we should
>> consider unstealthing the tool either for 2.7.0 (if immediate support is
>> available) or perhaps for 2.7.1 (allowing the team some ramp up time).
>>  Schools can take over the tool by forming a conventional team (e.g. like
>> the msgcntr or samigo teams) or contribute one or more resources to the
>> maintenance team that can focus on it (as has occurred recently when I
>> invited David Roldan Martinez to join the maintenance team to work on i18n
>> issues).
>> We should be firm when it comes to unsupported/abandoned tool code in core
>> Sakai: the tool gets marked as deprecated and stealthed in sakai.properties
>> for the upcoming release.  A community alert regarding the change in status
>> should be issued and institutions with a stake in a deprecated tool should
>> be invited to step forward to help maintain it.  If no one steps forward the
>> tool is targeted for removal in the next minor release.
>> We generate releases for the benefit of the entire community not single
>> institutions.  Given this we should be wary of permitting
>> unsupported/abandoned code to exist in production releases because one
>> institution or another may be inconvenienced by either stealthing or
>> removal.
>> If anyone objects to the plan outlined above regarding the next QA tag
>> please reply on list.
>> Cheers,
>> Anth
>>
>> Begin forwarded message:
>>
>> From: Anthony Whyte <[hidden email]>
>> Date: March 13, 2010 1:50:23 AM GMT+02:00
>> To: Clay Fenlason <[hidden email]>
>> Cc: "May, Megan Marie" <[hidden email]>,
>> "[hidden email]" <[hidden email]>,
>> "[hidden email]" <[hidden email]>,
>> "[hidden email] Developers"
>> <[hidden email]>
>> Subject: Re: [Building Sakai] [Management] 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/
>>
>> On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:
>>
>> Thanks for the clarification, Noah.
>>
>> It still, however, leaves us in a situation where we've heard from two
>> institutions that use Reports in production (IU and RI), and there may
>> be others we haven't heard from. I think we need to assume so, nor can
>> we assume that all such institutions are able to work with the source.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
>>
>> I made a change to address a static code review finding. Things were broken
>>
>> afterwards. I reverted that change and do not plan to try again to address
>>
>> the static analysis concern.
>>
>> I am, for my part, done with reports for 2.7 and concur with the
>>
>> recommendation to move to contrib. To speak plainly, I see it as a
>>
>> functional trap that suggests desirable functionality but leads to much
>>
>> wandering and confusion. Michigan does not plan to support the tool. Others
>>
>> might, but I still recommend it live in contrib. I thank John for his honest
>>
>> appraisal.
>>
>> The functional and technical investment requirements for usage warrant, to
>>
>> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>>
>> where this is the first "skill test" of many.
>>
>> I, personally, cannot speak to the tools' status, whether functioning as
>>
>> intended or not. I do not use them and do not know the code. They are as
>>
>> they were, as far as the code is concerned.
>>
>> Thanks,
>>
>> -Noah
>>
>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>
>> That may be the case, but I checked with Noah and Chris on Friday -
>>
>> while the larger thread was still unspooling - and I've reported what
>>
>> they told me then. If I misunderstood, happy to hear it.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>>
>> wrote:
>>
>> Hi Clay
>>
>> One point of clarity bellow
>>
>> 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.
>>
>> This looks to me hasty. The fact that it is outside the MT's capacity
>>
>> to maintain does not strike me as a decisive argument. It comes a
>>
>> little too close to asking the code to conform to the shape of the MT
>>
>> rather than the other way around, and it might be a better answer to
>>
>> recruit broader expertise for the MT. I don't think it's imagined that
>>
>> all maintenance would be completed by the maintenance team, especially
>>
>> during these formative stages of its growth.
>>
>> Now, if the MT can't maintain it *and* there is no other community
>>
>> resource that can help, that's a stronger case. But as I understand it
>>
>> the blocker issues for Reports are going to be examined by Noah, who
>>
>> thinks it might be corrected by backing out some earlier work, while
>>
>> we've heard that IU uses Reports in production.  My impression is that
>>
>> the apparent lack of community support is a matter of slowness in
>>
>> responding to this blocker, not that we have no remedy.
>>
>> We should probably take John Bush's insight to heart, that we should
>>
>> be looking for better solutions longer term. But dropping these for
>>
>> 2.7 seems to me precipitous at this stage of the release cycle.
>>
>>
>>
>> The MT recommendation was made in support of Alan's recommendation on
>>
>> the 10th, that in turn was based on Noah's submission (as I understand
>>
>> it) that the OSP team was unable to support these tools.
>>
>>
>> Regards
>>
>> David
>>
>>
>> _______________________________________________
>>
>> 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"
>>
>>
>>
>>
> _______________________________________________
> 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
John Norman John Norman
Reply | Threaded
Open this post in threaded view
|

Re: MT deprecation recommendations for 2.7

In reply to this post by Clay Fenlason
Is someone keeping track of the pros and cons of the various proposals? If it comes to a decision in which I am asked for an opinion I would prefer to analyse something along the lines of:

Doing XXX provides the following savings/benefits [to whom]... and it has the following costs/disadvantages [to whom]

Thanks
John

On 17 Mar 2010, at 18:19, Clay Fenlason wrote:

> Anthony:
>
> Sorry that your earlier note slipped past me, and that I then retrod
> much of the same ground.
>
> What you've proposed sounds consistent to me with our informal
> deprecation policy and the comments others have made on list recently.
>
> With perhaps one exception. It's not clear to me what the consensus is
> on the JCR service. Stephen questioned its removal (presumably to
> contrib) given that at least one known tool makes use of it. Ian then
> confirmed that Cambridge also has it running in production. Ian has
> said it's ok with him to move it into contrib, but I take that in the
> same spirit in which it's ok with Noah if OSP tools go into contrib -
> they're both comfortable making the code do what they want it to, and
> we need to also be concerned with others who can't adapt as quickly.
>
> But given the range of options available (eg. leave it in trunk or a
> source checkout, but not a release binary, etc.) it's not clear to me
> what the right balance is to strike with the JCR Service, apart from
> the fact that it seems best not to move it to contrib straight away.
> I'm not proposing a particular solution, I just want to be clear on
> where consensus opinion has come down, or at least get something
> spelled out that makes people realize we need to hash it out some
> more.
>
> ~Clay
>
> On Sun, Mar 14, 2010 at 7:40 PM, Anthony Whyte <[hidden email]> wrote:
>> In an earlier email I provided clarification regarding the MT's list of 2.7
>> deprecation recommendations and I have seen no compelling arguments that
>> suggest we should undertake a different course of action with respect to
>> mailtool, presentation, reports, warehouse and blog.   So I plan to do the
>> following for the next QA tag (sakai-2.7.0-b05), scheduled for Monday, 22
>> March 2010.
>> Deprecated as of 2.6.0, remove from 2.7.0
>> 1. Mailtool: remove the project from svn .externals and eliminate it from
>> the tag.  When convenient we migrate mailtool to contrib and eliminate it
>> from trunk/2.7.x.
>> 2. Presentation: remove the project from svn .externals and eliminate it
>> from the tag.  When convenient we migrate presentation to contrib and
>> eliminate it from trunk/2.7.x.
>> Unsupported trunk/2.7.x code
>> 1. Stealth reports
>> 2. Stealth warehouse
>> 3. Stealth blog
>> When I get back to the US I will start work on the 2.7.0 install guide and
>> release notes.  The release notes will list blog, reports and warehouse as
>> deprecrated and targeted for removal in the next Sakai 2.x minor release
>> (e.g., 2.8.0).  A stealthed tool can be unstealthed by a property override;
>> an option that in my view does not impose an undue burden on school's that
>> want/need to run blog, reports and warehouse in 2.7.
>> If one or more institutions wish to step forward and provide active support
>> for either reports (e.g., IU for instance), warehouse or blog we should
>> consider unstealthing the tool either for 2.7.0 (if immediate support is
>> available) or perhaps for 2.7.1 (allowing the team some ramp up time).
>>  Schools can take over the tool by forming a conventional team (e.g. like
>> the msgcntr or samigo teams) or contribute one or more resources to the
>> maintenance team that can focus on it (as has occurred recently when I
>> invited David Roldan Martinez to join the maintenance team to work on i18n
>> issues).
>> We should be firm when it comes to unsupported/abandoned tool code in core
>> Sakai: the tool gets marked as deprecated and stealthed in sakai.properties
>> for the upcoming release.  A community alert regarding the change in status
>> should be issued and institutions with a stake in a deprecated tool should
>> be invited to step forward to help maintain it.  If no one steps forward the
>> tool is targeted for removal in the next minor release.
>> We generate releases for the benefit of the entire community not single
>> institutions.  Given this we should be wary of permitting
>> unsupported/abandoned code to exist in production releases because one
>> institution or another may be inconvenienced by either stealthing or
>> removal.
>> If anyone objects to the plan outlined above regarding the next QA tag
>> please reply on list.
>> Cheers,
>> Anth
>>
>> Begin forwarded message:
>>
>> From: Anthony Whyte <[hidden email]>
>> Date: March 13, 2010 1:50:23 AM GMT+02:00
>> To: Clay Fenlason <[hidden email]>
>> Cc: "May, Megan Marie" <[hidden email]>,
>> "[hidden email]" <[hidden email]>,
>> "[hidden email]" <[hidden email]>,
>> "[hidden email] Developers"
>> <[hidden email]>
>> Subject: Re: [Building Sakai] [Management] 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/
>>
>> On Mar 14, 2010, at 9:48 PM, Clay Fenlason wrote:
>>
>> Thanks for the clarification, Noah.
>>
>> It still, however, leaves us in a situation where we've heard from two
>> institutions that use Reports in production (IU and RI), and there may
>> be others we haven't heard from. I think we need to assume so, nor can
>> we assume that all such institutions are able to work with the source.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 3:29 PM, Noah Botimer <[hidden email]> wrote:
>>
>> I made a change to address a static code review finding. Things were broken
>>
>> afterwards. I reverted that change and do not plan to try again to address
>>
>> the static analysis concern.
>>
>> I am, for my part, done with reports for 2.7 and concur with the
>>
>> recommendation to move to contrib. To speak plainly, I see it as a
>>
>> functional trap that suggests desirable functionality but leads to much
>>
>> wandering and confusion. Michigan does not plan to support the tool. Others
>>
>> might, but I still recommend it live in contrib. I thank John for his honest
>>
>> appraisal.
>>
>> The functional and technical investment requirements for usage warrant, to
>>
>> me, an opt-in strategy (contrib installation). Consider it "advanced mode"
>>
>> where this is the first "skill test" of many.
>>
>> I, personally, cannot speak to the tools' status, whether functioning as
>>
>> intended or not. I do not use them and do not know the code. They are as
>>
>> they were, as far as the code is concerned.
>>
>> Thanks,
>>
>> -Noah
>>
>> On Mar 14, 2010, at 2:54 PM, Clay Fenlason wrote:
>>
>> That may be the case, but I checked with Noah and Chris on Friday -
>>
>> while the larger thread was still unspooling - and I've reported what
>>
>> they told me then. If I misunderstood, happy to hear it.
>>
>> ~Clay
>>
>> On Sun, Mar 14, 2010 at 2:51 PM, David Horwitz <[hidden email]>
>>
>> wrote:
>>
>> Hi Clay
>>
>> One point of clarity bellow
>>
>> 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.
>>
>> This looks to me hasty. The fact that it is outside the MT's capacity
>>
>> to maintain does not strike me as a decisive argument. It comes a
>>
>> little too close to asking the code to conform to the shape of the MT
>>
>> rather than the other way around, and it might be a better answer to
>>
>> recruit broader expertise for the MT. I don't think it's imagined that
>>
>> all maintenance would be completed by the maintenance team, especially
>>
>> during these formative stages of its growth.
>>
>> Now, if the MT can't maintain it *and* there is no other community
>>
>> resource that can help, that's a stronger case. But as I understand it
>>
>> the blocker issues for Reports are going to be examined by Noah, who
>>
>> thinks it might be corrected by backing out some earlier work, while
>>
>> we've heard that IU uses Reports in production.  My impression is that
>>
>> the apparent lack of community support is a matter of slowness in
>>
>> responding to this blocker, not that we have no remedy.
>>
>> We should probably take John Bush's insight to heart, that we should
>>
>> be looking for better solutions longer term. But dropping these for
>>
>> 2.7 seems to me precipitous at this stage of the release cycle.
>>
>>
>>
>> The MT recommendation was made in support of Alan's recommendation on
>>
>> the 10th, that in turn was based on Noah's submission (as I understand
>>
>> it) that the OSP team was unable to support these tools.
>>
>>
>> Regards
>>
>> David
>>
>>
>> _______________________________________________
>>
>> 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"
>>
>>
>>
>>
> _______________________________________________
> sakai-qa mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
>
> 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"