On 11 May 2011 20:50, Tim Donohue <tdono...@duraspace.org> wrote:
> I can definitely see you point about also improving documentation. But as
> DSpace is now nearly 9 years old and we still haven't found "easy enough"
> documentation, I'm not sure I'm in full agreement that we'll ever be able to
> provide clear enough documentation for everyone.
>
> In addition, the main reason for this idea of an "easy installer" was to
> try and free up more of our Committer/developer time. If you notice, we
> still receive a ton of dspace-tech questions regarding installation problems
> (e.g. "Maven error", "Ant error", "problem compiling", "Why am I getting
> this weird error when I follow the Install instructions?").
>
But what I still don't think we've answered properly is - who is the
audience for the documentation / installer, to what end are we providing it,
and what are the consequences of doing so?
You say we haven't found "easy enough" documentation, but one thing that
strikes me - we don't actually make a clear statement as to who we think the
documentation is pitched at, and the knowledge they should have. How many
problems are caused by someone thinking they can work through the
instructions, when they could/would pass it over to an IT department if only
it had been made clearer up front?
Maven / Ant errors seem to be largely due to wrong versions being used -
mostly because we're quite limited on range of acceptable Maven versions
(we've used new features that require 2.2+, but have a structure with
autodetection that means 3.0 breaks). We can ease that by increasing the
compatability across versions, and/or by including supported versions in the
download packages (but not in the source repository).
Why are people installing it locally? If you want to play with the
interface, there is demo.dspace.org. We can provide complete, configured VMs
for people that want a clean slate. OK, I know we don't have that right now,
and VMs aren't for everyone, but there has to be a reason why someone would
choose to install it, versus the other options we do or could provide.
It's crucial to know that. Yes, we get questions about the Maven process.
But after you've got through that once, you are in much better standing to
start configuring and branding the repository. So you've used the easy
installer, and you've got a repository up and running. Now you want to
customize it - so that's your first question, and you get the answer that
you need to download the assembly distribution, configure the overlays, use
the Maven instructions and - what then?
If there is an easy installer that avoids doing anything with the assembly
project / Maven, then we should be confident that enough people could be
able to use it [for the whole of their evaluation] without needing to use
Maven and the assembly project. If it simply repackages the assembly project
with a working Maven and a facade for answering the basic questions and
kicking off commands, maybe an XML patcher for enabling 'supported' addons -
we probably can avoid those installation questions, even though they are
customizing their installation.
> How much of the software you use daily asks you to first compile it before
> you install it? Even other IR software (Fedora, EPrints) comes with an Easy
> Installer option (EPrints even offers 'rpm' and 'deb' options for extremely
> quick Linux based installs).
>
If you are only using the assembly / overlay projects, then you are not
compiling DSpace. And even so, it's unfair to compare the installation of a
word processor, or web browser.
And actually, it's entirely possible to create .rpm or .deb for DSpace - and
in doing so we can add dependencies on Tomcat, Postgres - allowing an
installation on a vanilla OS with just one command. But it would be a
signficant effort, more so than EPrints, and still doesn't really answer the
question of people wanting to brand / customize the repository after
installation.
> So, in my mind, it's *easier* for us to maintain a single "Easy Installer",
> than to maintain N*M combinations of "easy how-to" docs, where N = number of
> versions of DSpace, and M = number of unique system setups (OS, DB, etc).
Although it may be a better approach to be clear about who should be
following the installation documentation than trying to make it easy for
everyone, it still shouldn't involve that many combinations. Rather, there
should be M docs for getting operating systems installed with all the
prerequisites up to a base, consistent standard. And then N docs for
installing DSpace on top of that configuration.
> I still agree we should strive to provide "easy how-to" documentation,
> where we can. But, wouldn't it be nice if we could just say: "Don't
> want/need to compile DSpace for yourself? Just go run this installer, it
> will ask you all the questions (in plain english/i18n) that you need to
> answer to get up-and-running, and then just start up your Tomcat."
But does being nice actually solve a real problem, or simply relocate /
delay it slightly? That's why we need a better understanding of who is
installing and why. And I'm fine with us saying we can't know that, and
taking a punt on an installer - but we need to be managing expectations
accordingly.
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
