...
Camel component issue - priority for next week's workshop
Next release planning
- Switching to a new conference line
- Notes from the field: HydraConnect
- Issues raised:
Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1742 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1754
- Constructive interop discussions: best practices and common us of PCDM
- F3 to F4 migration interest group
- Issues raised:
- Scale/performance opportunities – brainstorm testing scenarios
- Vagrant refactoring: new base-box?
Landing in-flight issues - revisited
Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=13202 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 - ...
...
Vagrant/Apache Camel Component Issue
Next week, David and Andrew D. Wilcox and A. Woods are to be at the Fedora Users Group meeting in Washington D. C.
...
Implement a patch (which works fine), or update the Visitor Class (an interface in Jena; this requires more work)
A. Soroka (ajs6f): Good with pull request as it stands
...
Coburn and Ruest coordinating who shall be maintainers
A. Woods:
- Call for maintainers for any of the
...
- following GitHub repositories
- webapp-plus: awoods
- transform: whikloj, acoburn
- audit is assumed to be
...
- This still leaves audit, message-consumer, and webapp-plus with 0 or 1 maintainers
Without owners, note that these modules are to be put on the fence, staying where they are
...
Let's say we do that...which modules to be released (not a huge deal)
Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1752 Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1706 Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1683
It was suggested in a previous release that release candidate branches be created
Let these float out there for testing (as integration tests alone may not be sufficient)
Are people in the position to do sanity testing (if candidate branches created over the next week)?
Ideally, all developers in Fedora who run into issues while testing would create a ticketFor example, the most Vagrant issues (tests are passing, but not working)
whikloj, acoburn, and Nick N. Ruest suggest the usage of release-candidate branches with a code freeze
...
Administrative Dashboard is also available for David and AndrewD. Wilcox and A. Woods
Dedicated for Fedora (no conflicts with DuraSpace)
...
Wilcox: Uncertain if this is offered
HydraConnect
2015
Unknown User (daniel-dgi) Daniel Lamb can speak to many of the exchangesRepository Interoperability
Two sessions...one was a preconference event on the night of 10/21/15 (Monday)
Not much on what Islandora is doing wrong for Fedora 4
Hydra focused upon what they are improving (e. g. binding their Views)
Discussion landing on PCDM as least common denominator
Islandora over Fedora 4...Hydra over same Fedora 4...ideally, be able to have an admin view of Fedora resources
Lot of interest among the group in moving Hydra forward
Abstraction in Fedora 4...a standardized API is currently being established
PCDM conversation in particular is moving forward within the community
Addressing issues of value to the Hydra community
Esme E. Cowles is progressing with a branch is moving towards resolving | Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
E-Tags
E-Tags are generated solely based upon last modified date (managed by ModeShape)
Doesn't always work...issue with inbound references (i. e. cases for referencing between repository resources)
Updating B so that it references A...updates timestamp for resource A
Some parties find this behavior to be valid and appropriate...because the one potential representation has been changed for A
Others which develop applications that rely on E-Tags find that changing the timestamps often can trigger failures
Strong E-Tags should be Weak E-Tags
Reasoning: Strong E-Tags are byte-for-byte identical with regards to response
With content negotiation, responses aren't byte-for-byte identical, but the E-Tags are same
Further, for a higher-level application (e. g. Hydra) weak E-Tags have additional benefits
Fedora 3 to 4 Migration Interest Group
Workshop at HydraConnect (all day on Monday, three parts)
Woods: Core features and hands-on exercises
Benjamin Armintor: Session on migration using fedora-migrate; ActiveFedora 8 connecting to fcrepo 3; ActiveFedora 9 connecting to fcrepo 4 and migrating the content
Lamb: Integrating with external components via Apache Camel...just used fcrepo-camel (didnt use reindexer, solr, triplestoreupdater); How can you integrate with Fedora using Camel (using routes defined in XML)
Re-ran migration utility...using Camel routes for image resources, filtered for just JPEG images, executed ImageMagick, and re-ingesting the thumbnail as a child of the resource with the image
Session later in week: Hydra, and migrating into fcrepo4 (A. Woods, B. Armintor on are in the interest group)
Hydra community is in the position: no active development for fcrepo3 stack; how do I get on to Fedora 4 then?
Hydra is strictly focused upon fcrepo 4; Hence, the IG was born (define practices, documentation around migration)
(Within Hydra context, a consistent way of migrating into fcrepo4)
...