[Building Sakai] [Management] MT deprecation recommendationsfor 2.7

Fri Mar 19 11:09:15 PDT 2010

fwiw, I'm in meetings at NYU today, but just wanted to quickly pipe up and
say that I plan to try to work this unified presentation up at some point
this weekend, if someone doesn't beat me to it.

~Clay

On Fri, Mar 19, 2010 at 9:16 AM, Michael Feldstein <
michael.feldstein at oracle.com> wrote:

>  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
>
>
> __________________________________________________________
>
> [image: 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
> 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> 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"
>
>
>
>
> _______________________________________________
> 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/e4649617/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100319/e4649617/attachment.gif 