On 10 May 2011 13:38, Robin Taylor <robin.tay...@ed.ac.uk> wrote:
> In the UK at least most sites do not have a
> dedicated repo developer. I also suspect most sites take the code from
> the downloadable zip and never go near SVN. There is already a Jira
> issue from the DCAT group asking for an install process that doesn't
> require the installer to get involved with Maven and Ant.
I'll repeat what I've said before, and say that we need to be careful about
what our cases and reasoning are.
I'm quite happy to see installations made simple, but this is an
institutional repository, not a word processor. You can't simply do away
with all technical knowledge for maintaining the service and expect it to
provide the preservation that it's meant to [at least not without bundling
in connections to commercial services that could be 'activated' in the front
end - but that would be a can of worms].
imho, I think we need a bit more input from non-programming system
administrators as to what the right balance is to achieve here.
And whatever we put in place, we need to ensure doesn't make doing things
that are more advanced harder. I've installed Fedora using their installer
package - which was easy - but it really didn't give much of a handle on how
I should go about developing changes, fixing bugs, upgrading an installation
to a custom build.
With that in mind, we also need to consider the overall impact on the
community. The less technical / development work that needs to be done by
the community, then the fewer resources will be allocated by the community -
and the more that needs to be done within the core release. If we make it
easy to install, but harder to start custom developing, then the fewer
custom community developments that will take place. And that leaves a
question as to who is paying for the 'core' development to take place
(because development doesn't happen purely out of love)?
> I think we
> risk alienating a section of the community if we don't provide an easy
> mechanism to add modules and/or find the source code.
It's something that needs a careful balance. I don't want to alienate large
sections of the community, especially over something that we can resolve
without alienating anybody. But you can't please everybody, all of the time,
either.
But we do need a to agree on an easily understandable, consistent
> approach. Should nothing other than the core 'dspace' module be included
> in the first instance and everything else be optional ?
imho, yes. I think that's clean and understandable. Although we are steering
away from calling everything else as 'optional', rather they are 'add ons /
alternatives'.
Just because something is in the core, doesn't mean that you can't configure
it, disable it and / or swap it out for something completely different. But
we need to be clear about what is included in a release, and what isn't -
and how our policies govern it.
G
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
