...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1. 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)
2. 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!'
3. 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
4. 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
5. 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

       Jira
       server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2086

       should be merged before due to the possible impact of the change
     • 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
6. Specification Sprint
   • possibly 1 week long rather than 2
   • maybe having two components
     1. focus on document/interaction models,
     2. 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
7. 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.