...
- Announcements
- Steering Meeting Update
- Fedora Core + Tools Release Update
- Done
- To be done
- https://github.com/fcrepo-exts/fcrepo-import-export
- fcrepo-upgrade-utils
- fcrepo-java-client
- fcrepo-migration-validator
- fcrepo-migration-utils
- PRs needing review and merging
- Some tickets
Jira server Fedora JIRA serverId 1fe6d535-c432-380f-b5c0-a7d3b2940ea4 key FCREPO-3790
- Community technical focus
- Bugs
- New Features
- Fedora ecosystem projects
- Camel Toolbox Release Update
- Issues
- Camel Toolbox new features Thomas Bernhart: docuteam would be interested to develop the following additional capabilities - is there any interest?
- Add abbility to rewrite IRIs that point to Fedora before updating indizes (Solr, Fuseki)
- Add a Kafka-Forwarder to Forward fcrepo-messages to Kafka
...
In Review
Expand Jira server DuraSpace JIRA jqlQuery filter=13100 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Please squash a bug!
Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 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
Notes
Announcements
Presentation coming up later this month (11/30), workshop for SWIB (?). Need more details on what is expected for another event on 11/12; Arran Griffith and Danny Bernstein will discuss. Also to discuss: pre-conference proposal for Code4lib in Buffalo, NY.
Steering Meeting Update
Had a meeting this week. No major news. Working on forming concept of "where Fedora goes from here." Clearer sense of future direction needed. There is ongoing work to form a strategic planning subcommittee. Not currently a perceived need for a "pivot" or major changes, but there are some new features (like OAI-PMH, analytics) that might be worth prioritizing for going forward. Strategic planning will also cover how to grow and sustain the program, what staffing needs are required for the future (especially after David's departure from his project role), etc. No major surprises when talking with stakeholders about obstacles to migration, etc. Since staffing is a common obstacle, do we need a service provider to offer migration as a service? (There is a Lyrasis Catalyst grant proposal pending from Ohio State to do market research into this service idea, which could inform future developments when completed). Danny Bernstein expressed sustainability concerns regarding the need to grow the developer base (since losing any of the current developers could be a significant setback). Danny has drafted a community survey; this may be a good time to run it – Arran Griffith will review it and send it out soon.
Fedora Core + Tools Release Update
fcrepo-ocfl-storage and core 6.1.0 have been released (along with all core dependencies). GitHub artifacts are updated. However, some final details are still needed: release notes, tidying up JIRA, etc. (work in progress). Danny Bernstein hopes to wrap that up tomorrow so that an announcement can be made.
Remaining components: No blockers for import/export. Some issues with licensing updates are now completed – some PRs remain to be merged. There were some issues with the Java client, including an old PR that had been overlooked (Danny Bernstein thinks it looks good and asked Ben Pennell to review/merge if time permits).
Some Tickets
FCREPO-3790 would be very useful to be able to provide: would be nice to get the Grafana dashboard into version control and have a Dockerfile that builds the container. Question: is there API access for creating a dashboard, or a directory where you can drop things for auto-import? (Danny Bernstein hasn't investigated yet, but it wasn't immediately obvious). If anyone is interested in a mini-Docker project, volunteers are encouraged to take this one on.
Community Technical Focus
Between now and the end of the year, the main focus is fixing bugs and helping with migrations/adoptions.
Most new features are happening in ecosystem projects like Camel Toolbox, and potential front-end project (some possible interest in this at Lyrasis).
Also an open question about providing analytics (i.e. summary page) in existing web application that pulls basic information from the database. Tickets need to be written for this if there is interest.
Camel Toolbox Release Update
Not quite ready yet; Danny Bernstein hopes to get to it next week or the following week (depending on availability; he's working on a Duraspace sprint soon).
Arran Griffith raised the issue of the video recording a demo of the Camel Toolbox. Demian Katz will try to get a recording covering the HTTP forwarder completed before 11/19 and will send it to Arran Griffith.
Camel Toolbox New Features
Thomas Bernhart proposed a couple of new services that might be useful.
There was some discussion of the role of Kafka in the ecosystem (it is independent from JMS, using its own protocols; there is bridge code available, but it may not be open-licensed); it is widely used and so being able to hook into it could be useful for institutions that do not want to have to set up a different ActiveMQ system for Fedora-related message routing. General consensus: probably not too hard to build Kafka support into the Camel Toolbox, since Camel has a Kafka component available.
The other issue involves being able to adjust Fedora IRIs when indexing to (e.g.) a triplestore, so if you are in a reverse-proxy situation, you can have viable links in your triplestore (instead of internal IRIs that are inaccessible). Danny mentioned that there is an existing property in Fedora that can be used to set the hostname used in JMS messages (fcrepo.jms.baseUrl) which might help with this use case. It was unclear whether this would fully meet the need (though it seems that it probably would not, based on the point in the process at which transformation would be needed). Thomas Bernhart suggested adding the ability to map certain IRI prefixes to different prefixes within the toolbox to provide an alternate solution to this use case. Also discussed: whether simple string replace would suffice, or if more complex logic might be needed. Question: how do you make this reusable so it can be injected into all the various tools that might benefit from it. Question: how do you make it sufficiently configurable? Question: can LDPath take care of this?