[Building Sakai] [Management] MT deprecation recommendationsfor 2.7

Fri Mar 19 09:13:59 PDT 2010

> interface, then it shouldn't leave the time-bomb ticking. Alan, Anthony,
> David Horwitz, Aaron: is that a fair assessment?

It is fair. I also can understand why people would use the covers
since it is easier than trying to understand dependency injection.
There are uses all over the core code as well (and quite heavily in
some places like search) but the MT plans to clean these up.
I feel like it is reasonable to leave them in for the life of the core
services they are attached to at this point with a "buyer beware"
deprecation marker on them.
-AZ


On Fri, Mar 19, 2010 at 3:59 PM, Ray Davis <ray at media.berkeley.edu> wrote:
> Despite being a long-time bad-mouther of static covers (maybe the
> longest, along with Josh), I have to admit that Noah's and David
> Haines's suggestions sound attractive. *Using* static covers certainly
> interferes with the writing of unit tests, but eliminating all use of
> them from core code is not quite the same as erasing them. Yes, that
> means shipping untested code, insofar as the covers *themselves* cannot
> be tested -- but presumably that's where deprecation and lint-complaints
> come in.
>
> The most difficult product management issue, as I understand it, is that
> existing cover-using legacy code outside control of the Maintenance team
> can be expected to sometimes break after new releases, and then the
> Sakai community would be stuck with either quickly fixing the
> (untestable) problem or with saying "Tough luck, that's why they're
> deprecated." In other words, if the community can't stand behind an
> interface, then it shouldn't leave the time-bomb ticking. Alan, Anthony,
> David Horwitz, Aaron: is that a fair assessment?
>
> Best,
> Ray
>
> On 3/19/10 5:57 AM, David Haines wrote:
>> You're quite right that there might be circumstances where static covers
>> are convenient for code development. On the other hand when people, like
>> the MT and QA and anyone fixing bugs, are dealing with code written by
>> others usage of static covers does get in the way.
>>
>> How about this:
>> - Deprecate the use of static covers.
>> - Do NOT remove them the covers themselves.
>> - Incrementally remove the use of static covers from core Sakai code.
>>
>> This will let people use static covers for code that only they are
>> responsible for without imposing the limitations of static covers on the
>> MT and QA.
>>
>> This is only my opinion. I don't know what QA and the MT would say.
>>
>> - Dave
>>
>> David Haines
>> CTools Developer
>> Digital Media Commons
>> University of Michigan
>> dlhaines at umich.edu <mailto:dlhaines at umich.edu>
>>
>>
>>
>>
>> On Mar 19, 2010, at 3:40 AM, Stephen Marquard wrote:
>>
>>> Let's just be clear on one point:
>>>
>>> It is not necessary to remove or even deprecate the static covers to
>>> enable unit testing for code.
>>>
>>> It may be necessary that the code which is being unit-tested does not
>>> use the static covers, but that is no obstacle to any other
>>> (non-unit-tested code, e.g. local tools, 3rd-party code) continuing to
>>> use the static covers.
>>>
>>> Regards
>>> Stephen
>>>
>>>>>> "Berg, Alan" <A.M.Berg at uva.nl <mailto:A.M.Berg at uva.nl>> 3/19/2010
>>>>>> 9:31 AM >>>
>>> Hi all,
>>>
>>> I like Noahs email as debate is most welcome as QA hopes to motivate
>>> an increase test coverage.
>>>
>>>> If someone had the
>>> resources to write the tests, they would exist. The fractional cost to
>>> switch off the covers is not why we don't have them.
>>>
>>> Agreed
>>>
>>>> I think the unit test scenario is a red herring.
>>>
>>> Disagree. If the MT agree to add tests as they maintain then we start
>>> to cluster and increase the regression testing around weak points.
>>>
>>> I am a great fan of unit like tests in combination with continuous
>>> builds. In Sakai 2.x if a bug is found I would promote the idea of
>>> adding tests around the cleaned code.If we run the builds say once
>>> every 2 hours with a praise mechanism then the community more
>>> aggressively avoids regression. I therefore think the current status
>>> of having limited test coverage is not an argument. I find David
>>> Haines suggestion of adding an extra method to get the instance in the
>>> cover rather intriguing and would enjoy more discussion. I also see
>>> Aarons point about ad-hoc improvement removing covers as code is
>>> maintained, as an incremental investment.
>>>
>>> Opinions?
>>>
>>>
>>>
>>> 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: sakai-dev-bounces at collab.sakaiproject.org on behalf of Noah Botimer
>>> Sent: Thu 3/18/2010 22:42
>>> To: markjnorton at earthlink.net
>>> Cc: Developers Sakai-Dev
>>> Subject: Re: [Building Sakai] [Management] MT deprecation
>>> recommendationsfor 2.7
>>>
>>>
>>> My thoughts here are simple and brief. My solution:
>>>
>>> 1. Remove all usage of covers from "the release".
>>>
>>> 2. Mark everything about them deprecated.
>>>
>>> 3. Keep them synchronized until 2015 (i.e., forever).
>>>
>>> 4. Add a Maven profile to lint the code and yell if any usage creeps back
>>> in.
>>>
>>> 5. Include a link in every file's Javadoc to a permanent page of
>>> instructions on how to use the profile to scan and the alternatives for
>>> contrib/local code.
>>>
>>> 6. Eat pizza with the money we save on not rewriting code.
>>>
>>> Everybody wins.
>>>
>>>
>>> I think the unit test scenario is a red herring. If someone had the
>>> resources to write the tests, they would exist. The fractional cost to
>>> switch off the covers is not why we don't have them.
>>>
>>> Thanks,
>>> -Noah
>>>
>>> On Thu, 18 Mar 2010 09:08:21 -0400, Mark Norton
>>> <markjnorton at earthlink.net>
>>> wrote:
>>>> Anthony Whyte wrote:
>>>>> 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?
>>>> For you and I - no. For a Java developer familiar with Spring -
>>>> probably not. However, I've trained dozens of developers in Sakai tool
>>>> development who are NOT familiar with Spring or even the concept of
>>>> injection. While admittedly a crude approach to solving the problem,
>>>> covers are considerably easier for non-Spring Java programmers, or
>>>> (perhaps more importantly) experienced non-Java programmers.
>>>>> 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.
>>>> What is the problem of writing unit tests and the presence of service
>>>> manager covers? If the cover is a method duplicate of the service
>>>> manager, unit tests should work equally well for both (with the addition
>>>> of the getInstance() method).
>>>>> 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.
>>>>>
>>>> I'd like to understand how it is in the way.
>>>>
>>>> - Mark
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>


-- 
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile