...
- Longshou Situ
- Unknown User (acoburn)
- Esmé Cowles
- Yinlin Chen
- Nick Ruest
- Bethany Seeger
- Aaron Birkland
- Jared Whiklo
- Jim Coble
- Andy Wagner
- Andrew Woods
- A. Soroka
- Jennifer Lindner
- Andy WagnerMichael Durbin Michael Durbin
- Marcus Barnes
- Jack Hill
- Jenn Colt
- Daniel Lamb
Agenda
- Should we move information in system-managed triples into HTTP headers?
- gradle in fcrepo-exts?
- Should we remove the ability to delete tombstones?
Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2207 - 2016 - 2017 Technical Priorities
- 4.7.0 release plan
- Specification Sprint - which and when
- PennState Import/Export sprint planning
- Priorities
- BagIt implementation design
- Remote participation possibilities
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2200 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2196 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2203 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2192
- ...
Status of "in-flight" tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=13202 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Ticket Summaries
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 jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 Tickets created this week:
Expand Jira server DuraSpace JIRA jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Minutes
- Should we move server-managed-triples into HTTP headers?
- Unknown User (acoburn) expressed concern that they must also appear in triples to facilitate indexing and so forth
- Esmé Cowles brought up the example of rdf:type being important
- The LDP spec may require rdf:type to show up in the triples, but the fedora-namespaced triples we can do what we want to with
- It's also unclear what standard headers we could use... especially for literals, which can't be the subject of link headers.
- Andrew Woods and Unknown User (acoburn) indicated that we should do an inventory of our server-managed triples, and we should consider cleaning up the ontology. (like number of children)
- experiment with gradle for fcrepo-exts projects?
- Unknown User (acoburn) really likes gradle; finds it superior to maven, and wondered if we could try it out in some projects
- Andrew Woods argued that consistency of build infrastructure makes it easier for community participants
- Unknown User (acoburn) stated that gradle has a much easier learning curve the maven (days vs months)
- It was brought up that for most non developers, the simple install command won't require much learning in either case.
- Aaron Birkland suggested we should at least include in the readme.md the command to build the code
- Several spoke up in favor of trying it out. No one vetoed the idea.
- There was consensus and we decided that the maintainers of extension projects may use gradle 'gradle on!'
- Should we remove the ability to remove tombstones?
- Andrew Woods, Unknown User (acoburn) both thought we shouldn't remove that ability at this time
- Unknown User (acoburn) thought the fcrepo-camel stuff shouldn't offer a way to easily delete them (even if its an undocumented feature)
- The fcrepo-java-client library offers no such special support
- We decided to close the ticket
- Development Priorities
- performance/scale has a working group that meets regularly so this is "moving along"
- runtime configurability was a priority earlier on (osgi and such) but is a somewhat lower top priority
- Unknown User (acoburn) has put the OSGI thing on hold until we get an alternative (to modeshape) implementation
- API specification needs some focused energy in the short term
- Since 4.6 is out, we need to start releasing 4.7
- Jared Whiklo volunteered to be release manager
- We need a release candidate ASAP (then a minimum of 3 weeks of user testing) - the plan is to get it out next week
- Jared Whiklo called out to anyone who had a pending ticket
- Michael Durbin said he didn't think
should be merged before due to the possible impact of the changeJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2086 - Unknown User (acoburn) wanted to fix a minor (secret) bug tomorrow, so we scheduled the code freeze for Monday morning
- An e-mail will be sent out today by Jared Whiklo
- Michael Durbin said he didn't think
- Specification Sprint
- possibly 1 week long rather than 2
- maybe having two components
- focus on document/interaction models,
- aligning fedora with specification
- Nick Ruest suggested we sort out the chain of dependencies before scheduling the sprints
- Andrew Woods asked whether it should be one or more specifications per sprint
- seemed to depend on who was available, though availability probably depended on how we attempted to recruit contributors
- Nick Ruest suggested we target people to work on them, and each spec has its own sprint-leader
- There was opposition to development in concert with specification
- Aaron Birkland suggested that a TCK (test) sprint would be a good follow-on sprint and that could drive the updates to the implementation
- Nick Ruest gave an update on the planned Import Export sprint
- most participants will be at Penn State, but...
- if people want to participate remotely, contact Nick Ruest ASAP, possible tickets are in the agenda above
Next week, Andrew Woods and those at DCFUG won't' be on the line, but there will be a meeting.