I have a couple of thoughts on this: If local customisations cause previously-passing unit tests to fail, those customisations have pretty much by definition broken the app. That being the case, should the user then blithely install the broken version of the app anyway? Alternatively, if those tests start failing and the app is actually fine, then the tests are broken and need to be fixed. I think both cases should be visible rather than hidden. I agree that making things more complex for DSpace admins who are not developers is something to be avoided, but as has already been mentioned, things are already more complex than they need to be because a development tool is being used by end users to install the app. I think there is merit in moving to an installation tool for end users; this to me is a much better idea than reducing the usefulness of the dev tool for developers in order to try and make it easier to do something the tool's not meant to be doing anyway.
I am in favour of a phased approach, as Stewart suggests. However, I think it might be worthwhile making fixing DCDate part of the first phase, and making the release of 1.7 contingent on DCDate being fixed. Then no broken tests need be shipped and the problem simply goes away. From personal experience, pretending that something is fine often leads to unpleasant reminders later. Alternatively, as also suggested, leave the test failing and have the users not run it on install. A failing test is something that tells us something useful; a test that wrongly tells us that the current behaviour is fine is much less useful. I appreciate that it's not my time I'm discussing, but I feel very strongly that at least some portion of the time being spent on the core needs to be spent on fixing some of the problems with it. Saying "we're not going to do it now" often turns out to be functionally equivalent to saying "we're not going to do it". Personal experience, once more. :) -- Simon Brown <st...@cam.ac.uk> - Cambridge University Computing Service +44 1223 3 34714 - New Museums Site, Pembroke Street, Cambridge CB2 3QH ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
