[Building Sakai] [Management] MT deprecation recommendationsfor 2.7

Fri Mar 19 06:16:55 PDT 2010

I would like to echo John's call to pull all of this together into a unified set of notes and proposed alternatives. Could somebody please start a Confluence page on this? If were technically capable of following this conversation and thus summarizing it faithfully, I would do it myself. But I am not, so could somebody else please do it?

- m

__________________________________________________________

Oracle Email Signature Logo
Michael Feldstein | Principal Product Manager| 818-817-2925
Oracle Higher Education Product Development
25 Christian Hill Road | Great Barrington, MA 01230

  _____  

From: David Haines [mailto:dlhaines at umich.edu] 
Sent: Friday, March 19, 2010 8:57 AM
To: Stephen Marquard
Cc: Alan Berg; Developers Sakai-Dev
Subject: Re: [Building Sakai] [Management] MT deprecation recommendationsfor 2.7

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 
HYPERLINK "mailto:dlhaines at umich.edu"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" <HYPERLINK "mailto:A.M.Berg at uva.nl"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"

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

______________________________________________________________________________________________ 

UNIVERSITY OF CAPE TOWN 

This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.

_____________________________________________________________________________________________________

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100319/03e93a89/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100319/03e93a89/attachment.gif 