...
Agenda
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
- 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 |
---|
|
- ...
...
Please squash a bug!
Expand |
---|
Jira |
---|
server | DuraSpace JIRA |
---|
jqlQuery | filter=13122 |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
|
|
Tickets resolved this week:
Expand |
---|
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
maximumIssues | 20 |
---|
jqlQuery | filter=13111 |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
|
|
Tickets created this week:
Expand |
---|
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
maximumIssues | 20 |
---|
jqlQuery | filter=13029 |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
|
|
Minutes
...
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.
They shall not be available for the next meeting
This features a Fedora 4 workshop (requires the spinning up of a Vagrant Box)
...
acoburn: fixes in review preferred to make it into a release (
Issues 1752 and 1706Issues 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 |
---|
|
and 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 |
---|
|
)
Issue 1706
Discussed between ajs6f and acoburn
...
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
...
acoburn: confirms, another ticket for Visitor within Jena would be good;
can create the Visitor ticketcreated a related ticket here: Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-1758 |
---|
|
GitHub Shuffle
Need to sort out maintainers on a number of GitHub repositories
A Technical subtask is outstanding (
Jira |
---|
server | DuraSpace JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | c815ca92-fd23-34c2-8fe3-956808caf8c5 |
---|
key | FCREPO-1745 |
---|
|
)
acoburn: Outstanding issues for these shouldn't hold up a release
awoods: These 6 repositories appear to have been moved out of fcrepo-labs, and into fcrepo-ext exts where appropriate
awoods: Just a matter of updating the README file for each of them
...
Coburn and Ruest coordinating who shall be maintainers
A. Woods:
- Call for maintainers for any of the
...
- following GitHub repositories
...
...
- transform: whikloj, acoburn
...
...
...
...
...
- 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 |
---|
|
- Issue 1752
- Issue 1706
- Issue1683
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 sandy sanity testing (if candidate branches created over the next week)?
Ideally, all developers in Fedora who run into issues while testing would create a ticket
For 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
...
The code freeze message, hence, shall be announced to the community
New Conference Line
Current line...costs money...about 4 cents per minute per person
Try to switch to free line...
Current conference line is quite expensive
D. Wilcox: New, free line is almost exactly the same...except without offering "1-800" toll-free numbers
With numbers from every country...long distance is likely to be a potential issue
Call for parties who may have difficulties with this
Canada offers free calls if it's a Canadian number
Administrative Dashboard is also available for D. Wilcox and A. Woods
Dedicated for Fedora (no conflicts with DuraSpace)
Try it next week....
Birkland: DuraSpace previously offered free conference call HD, accompanied with a Skype back-channel for conference calls...is this similar?
Birkland: This could mitigate issues by offering access over Skype if this is offered
Wilcox: Uncertain if this is offered
Unknown User (daniel-dgi) 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
E. Cowles is progressing with a branch is moving towards resolving 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 |
---|
|
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
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
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 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)
Exercising the limits of the Fedora stack
People are being drawn to the fcrepo4 projectCurrent and potential scalability appeals to these new parties
Concrete descriptions of tests are desired
These render it easier for individuals coming into project...leading to the creation of infrastructure and the addressing of testing
Infinispan and the potential of the fcrepo4 stack (particularly focusing upon scalability targets)
Create isolated test scenarios
Interested Parties
- whikloj
- osmandin
- acoburn
- awagner
- jrgriffiniii
- ajs6f (Volunteering to Help)
Call to starting a Google Doc
Over the next couple of weeks, collectively come up with a test plan
Please include everyone in the community if this is initiated; otherwise, A. Woods will address after traveling
This should be an outline of a test plan...again, refer to the work of the Technical WG
Examples of Test Cases:
- Scaling for resources
- Scaling for a number of bytes
- scaling for a large repository collection
- iterating over reads
- performing an operation offline and pushing back updates
- at each resource, POSTing back an update
Include references for components at the Infinispan layer
Also discuss deployment into the cloud (particularly AWS)
Cleaning up Vagrant
N. Ruest has progressed much with the Islandora ecosystem
Vagrant Box with main components installed in the base box
Pulls down pertinent versions of Fedora components...installing all of the infrastructure for the Box
Question of Packer/Vagrant for Docker?
Deep-dive for next installation...sorting out the Vagrant/Packer discussion
Still need expertise for Packer
N. Ruest: Each institution requires its own Vagrant
ksclarke: has a number of features which he has to offer