I'd actually rather see some documentation exposed at those points so that
folks could actually get the access details for the service.
For instance, parse the service document and offer examples neccessary for
accessing the service
Mark
On Friday, March 16, 2012, Hardy Pottinger (Created) (Dura
As I thought about this a bit more, I did somewhat have a change of heart,
and kind of think we ought to "properly" redo it.
Imagine when DSpace migrates to xyz-version-control in a decade. We'll all
be emeritus, and wondering where our place in history is. And the future
people migrating the cod
On Wed, Mar 14, 2012 at 11:53 AM, Peter Dietz wrote:
> Hi All,
>
> Since we're now ready to migrate all of the remainder code to GitHub, two
> questions have popped up.
>
> 1) Should we stick with the existing Github.com/dspace/dspace repository,
> or should we reimport (a fresh git svn clone) so
Java.io.IOException: No such file or directory error on file uploads or updates
---
Key: DS-1143
URL: https://jira.duraspace.org/browse/DS-1143
Project: DSpace
Issue
Maybe a more simple perspective.
1.) Fork, Pull and Branch is best for non-commiters and external projects.
IE, if your going to run a local DSpace instance and want to maintain your
customizations in github or if you are working on addons or other fun
things that are not considered "central".
2.
Hello DSpace Developers,
In the essence of openness, I wanted to let you all know that,
unfortunately, DuraSpace was rejected from Google Summer of Code 2012.
At this time, it's unclear why our application was rejected. DSpace has
had an amazing run of GSoC acceptance for five years straight (2
[
https://jira.duraspace.org/browse/DS-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hardy Pottinger updated DS-1142:
Summary: add redirects to SWORD/OAI/LNI interfaces (was: add redirects to
SWORD/OAI/LNI interfacts)
add redirects to SWORD/OAI/LNI interfacts
-
Key: DS-1142
URL: https://jira.duraspace.org/browse/DS-1142
Project: DSpace
Issue Type: Improvement
Affects Versions: 3.0
Reporter: Hardy Pot
Hi Mark,
Yes, you are correct of course. The two approaches are not mutually
exclusive. But, I do feel we need to develop our own best practices
around which approach(es) we recommend for which cases.
In other words, if all the Committers are taking different approaches to
collaboration, then
