our entire repository (~96,000 items) every
> night like this:
>
> $ dspace curate -t countrycodetagger -i all -s object
>
> The scope parameter seems to have helped, if I recall correctly when I
> originally wrote this a few years ago.
>
> Regards,
>
> On Sat, Feb 12, 2022 a
gt;
> I'm mostly working with Python in my full-time job now, so this might be a
> good way for me to get back in touch with DSpace :-)
>
> Op woensdag 16 februari 2022 om 04:49:03 UTC+1 schreef Kim Shepherd:
>
>> Hi all
>>
>> In the process of planning a conten
Hi all
In the process of planning a content migration, we've got a basic Python
REST API client for DSpace working with basic CRUD operations for
bitstreams, bundles, items, collections, communities:
https://github.com/the-library-code/dspace-rest-python
I'll keep it updated with any further
Hm, this does sound like a problem, I may not have noticed it myself as I
typically do put in Context commits within my performItem() implementation
anyway.
Could it be as simple as doing a commit after calling performObject in
distribute(), and maybe decaching the dso at the end of distribute()?
Hi all, you'll have noticed the further delays to DSpace 6.4... hopefully
close to the finish line, now.
The more eyes / hands we can get testing
https://github.com/DSpace/DSpace/pull/2918 (especially in XMLUI which has
had less production usage) the quicker we can get a long-needed release out
Hi all,
We're still working on a few bigger PRs for 6.4 and some new important bugs
that just got reported, but we are hopefully nearing the point of freeze
and test. Obviously if some tasks end up slowing down the process too much,
we'll have to start triaging for a future 6.5.
I won't
p & closed in a manually created JSON file. Just my two cents here though.
>
> Tim
>
>
> --
> *From:* dspace-devel@googlegroups.com on
> behalf of Kim Shepherd
> *Sent:* Monday, May 4, 2020 9:22 PM
> *To:* DSpace Developers
> *Subject:* [dspace-devel] R
Hi all,
We're making good progress on 6.4, particularly the larger improvements
that we really want to get into the release rather than making them wait
for DSpace 6.5.
We had earlier anticipated a code freeze of April 14 but I think we need to
push this out again to give time for a bit more
Hi all,
We're still working on getting reviews, tests and merges done for DSpace
6.4, and inevitably a few improvements have cropped up that would be
*really* nice to get into this release, but are a bit larger than a typical
bugfix and so need a bit more attention.
eg.
-org.slack.com)
Cheers!
Kim Shepherd
(on behalf of the DSpace 6.4 release team / DSpace committers)
--
All messages to this mailing list should adhere to the DuraSpace Code of
Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed
Hi Alan,
Thanks for this prod - a few of us have been discussing this very thing.
I think we're agreed that it's been so long, that we shouldn't tarry with a
6.4 release (sometimes release planning announcements lead to a bit of
scope creep where the waiting list gets longer), but at the same
Sounds painful! Shall we remove that redundant layer in a future
4.x/5.x/6.x release? Would probably count as a "minor release" improvement,
I'm guessing?
-k
On Tue, 26 Nov 2019 at 09:23, Mark H. Wood wrote:
> What fun.
>
> I wanted to create a new link in the Statistics options block. But
Hi Marc, I could see this working.
You'd have to decide what to do in the event of multiple values for this
metadata field in a single collection (take first? throw error?), but as
this change would probably involve changing the Edit Collection form
anyway, you could probably enforce
Hi all,
Has anyone noticed a connection between curation tasks and the "idle in
transaction" postgres sessions we sometimes see in DSpace (5.x and earlier,
at least) when a transaction/connection hasn't been closed or completed
properly?
There are a couple of methods
warded message --
From: Kim Shepherd <k...@shepherd.nz>
Date: 18 May 2018 at 09:39
Subject: DSpace 6.3 Status Update - Release target May 21
To: DSpace Developers <dspace-devel@googlegroups.com>, DSpace Technical
Support <dspace-t...@googlegroups.com>, DSpace C
Hi all,
We are still on track for a May 21 (UTC) release date of DSpace 6.3. Thanks
to all those who have chipped in and helped with pull requests, code
reviews, testing, and joining the conversation.
We've made good progress on testing and merging code contributions, and now
that we're a few
*sigh* Last attempt! http://www.timeanddate.com/worldclock/fixedtime.html?
hour=20=0=0=0
0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC
On 25 April 2018 at 17:43, Kim Shepherd <k...@shepherd.nz> wrote:
> Sorry, that world clock link should be http://www.timeanddate.com/
>
onvert properly from 20:00 UTC -- copy paste error!
-k
On Wednesday, April 25, 2018 at 5:39:20 PM UTC+12, Kim Shepherd wrote:
>
> All,
>
> Tomorrow(ish) (Weds, April 25) at 20:00 UTC, we have our weekly DSpace
> Developers Meeting in the #duraspace IRC
> <https://wiki.duras
Hi all,
Progress is being made toward DSpace 6.3, but it's becoming obvious that a
lot of existing contributions made for the DSpace 6.x codebase will have to
be postponed for 6.4 in order to release 6.3 in a timely manner.
We are currently aiming for a release on May 1st, which probably means a
Hi all,
It's been a while since DSpace 6.2 was released, and in that time a lot of
fixes and improvements have been identified.
There's currently a push to get a version 6.3 released soon. But we can't
do it alone!
If you know of an open JIRA issue or contribution that you really want to
see
Made a long comment at the end of the doc so thought I'd post it here too!
Should we be thinking about the models/schemas/ontologies used for
representing the (likely) core entities, as well as the nuts'n'bolts
implementations of how the DB tables, business layer methods are going
to work?
21 matches
Mail list logo
