Page History
...
- (30 mins) General Discussion Topics
- Discuss design of Bulk access control management (previously called "Advanced Policy Manager" in 6.x) - The ability to modify policies on several items/bitstreams at once. (UI ticket #781,REST ticket #2848)
- Ideally, we should scope this to be as simple as possible to achieve the same "use cases" in DSpace 7. The feature can be redesigned but also should be simplified.
- Known Use Cases include: (Neither of these are currently possible in 7.5)
- Access restricting (or giving access to) all Items in a Collection,
- Access restricting/embargoing (or giving access to) all Bitstreams of all Items in a Collection.
- Replace all polices or append to existing policies in either use case
- (4Science addition: modify all policies within a single Item to restrict or access restrict all in a single Item. Similar to Submission or Workflow you could use access settings.)
- Bulk access control management - 4Science proposal
- Planning for 7.6
- 7.6 board has been cleaned up & is ready. However, need help from Atmire/4Science on the "In progress" column.
- General rule for 7.6: New features are welcome if they used to exist in 6.x. Everything else must be a fix that would normally be acceptable in a "bug fix only" release.
- 7.6 is a "transition" release, where we are transitioning back to our release numbering scheme
- Timeline for 7.6: Looking at a June release (unless we find that upcoming/planned 7.6 development can be done sooner than anticipated)
- TODO: Tim will update release schedule above.
- Releases after 7.6: Later releases will be bug-fix only.
- Andrea Bollini (4Science) and Lieven Droogmans suggest to switch to a 7.6.1, 7.6.2, 7.6.3 for eventual bug fix release. This clarifies that 7.6 is the final feature release, and that every later release is a minor upgrade.
- With 8.0 however, we would move back to our existing release numbering scheme. Bug fix releases would be numbered 8.1, 8.2, 8.3, etc.
- (Future Topic) Lyrasis' new CEO has asked Tim Donohue to investigate what it would take to implement OCFL-based storage (or similar preservation-friendly storage) for DSpace (v8 or later)
- Early brainstorm is to likely keep DSpace's existing database & Solr usage as-is.
- However, migrate from current "[dspace]/assetstore" to an OCFL storage structure.
- OCFL storage would contain both the content file(s) (PDF, etc) and a metadata representation (exported/synced from database). The metadata representation might be similar to our existing DSpace AIP Format.
- Tools would need to verify/validate that data in OCFL storage "matches" with what is in the database (similar to a Checksum Checker, but more specific to OCFL storage)
- ANYONE interested in brainstorming this idea further, perhaps even in a separate meeting?
- (NO UPDATES) Demo Site maintenance (https://demo7.dspace.org/ and https://api7.dspace.org/server/)?
- LYRASIS is still working on this, but some restructuring of plans has had to occur because of internal deadline changes. Likely not to be completed until late March or April.
- In the meantime, can we ensure that it is still possible to send updates to both the frontend & backend per instructions at Updating DSpace 7 Demo Sites
- (Other topics?)
- Discuss design of Bulk access control management (previously called "Advanced Policy Manager" in 6.x) - The ability to modify policies on several items/bitstreams at once. (UI ticket #781,REST ticket #2848)
- (30 mins) Planning for next week
- Review the Backlog Board - Are there any tickets here stuck in the "Triage" column? We'd like to keep this column as small as possible.
- Review the 7.6 Project Board - Assign tickets to developers & assign PRs to reviewers.
- Paid (by DSpace project) developers must keep in mind priority. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks.
- Volunteer developers are allowed to work on tickets regardless of priority, but ideally will review code in priority order
...
Overview
Content Tools