Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

  • Time: 11:00am Eastern Daylight Time US (UTC-4)
  • U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
  • International toll free:  http://www.readytalk.com/intl 
    • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
    • Once on the call, enter participant code 2257295
  • IRC:

Attendees 

Agenda

  1. Islandora
    1. migration-utils work
    2. auditTrail/log migration
  2. Audit sprint progress
    1. Phase 1 (event-based audit system using Camel) ready for test: Verification - Event-Driven Audit Events
  3. Codebase test policies
    1. What are the purposes for our unit testing? (Hint: they don't include high coverage numbers for their own sake.)
    2. What are the purposes for our integration testing?
    3. How do we know when tests are needed, and when they are, which kind(s)?
  4. PCDM ontology committers and scope
  5. 3.8.1-RC3
  6. F4 export/import and content-negotiation


Minutes

  1.  Islandora
    1. Migration work: Unknown User (daniel-dgi) finished work on Unable to locate Jira server for this macro. It may be due to Application Link configuration. , identifying F4 predicates for F3 datastream properties.
    2. Working now on identifying everything in the F3 audit trail and migrating that into the F4 audit structure. Unknown User (escowles@ucsd.edu): mapping from F3 to F4 could be a good fit for external events. Nick Ruest asks for feedback on the islandora documentation in case anything was missed. Unknown User (escowles@ucsd.edu): should use existing vocabularies or add to existing audit vocabulary. Andrew Woods: supporting the F3 audit stream should be a requirement for the F4 audit service.
  2. Audit sprint progress
    1. Phase 1: ready for testing. The vagrant project has been updated with the camel-based audit system, which pushes audit events into an external triplestore. External events can be added directly to the triplestore. Andrew Woods will send out a message to the community soliciting feedback, requesting testing of the vagrant-based system, and providing a summary of the sprint. (This will be sent to fedora-tech and fedora-community, but not hydra/islandora)
    2. Phase 2: in which F4 creates internal nodes for audit events, but not as part of the default F4 distribution. This currently exists as an extension module in fcrepo4-labs, and will become part of fcrepo-webapp-plus (not bundled with authentication)
      1. Andrew Woods: we need a way to make it easy to configure fcrepo-webapp-plus
      2. Noted that Unknown User (acoburn) assembled the OSGi-based camel route as a web-deployable war file. Reportedly, it was easy to do.
      3. A. Soroka: this type of module configuration is solved with OSGi, but doing this for F4 would involve a significant investment in developer resources. At the very least, it would require more than one person.
  3. Testing policies
    1. fcrepo-client currently has minimal integration tests and flawed unit tests that no longer reflect how F4 responds to requests.
      1. Michael Durbin: integration tests would be a much better measure for this.
      2. A. Soroka: how much is enough? What is a policy?
      3. Michael Durbin: code coverage is used as a proxy for testing quality.
      4. Andrew Woods: 75% is the current target; projects without an explicit policy suffer from insufficient test coverage
      5. A. Soroka noted that a standard does not imply a certain line coverage number; furthermore, it would be better to test behavior and expectations, making clear what those expectations are. This is not unrelated to documentation. It is important to distinguish between coverage of getter/setter methods and more substantive methods.
      6. Unknown User (acoburn): consider looking at the branch coverage numbers reported in sonar
      7. A. Soroka: also cyclic complexity or other, more appropriate, metrics.
      8. TODO: Andrew Woods to find 2 or 3 classes with particularly bad test coverage; as coverage improves for those, what other metrics change, and might those be better measures of code quality?
    2. Where are unit tests vs. integration tests useful
      1. Andrew Woods: unit tests can expose an overly coupled design
      2. Unknown User (acoburn): unit tests can be helpful when refactoring
      3. Michael Durbin: it is also pointless to write tests that will be discarded later, especially if many of those tests are effectively meaningless (e.g. testing getters/setters) or impede community contributions to the code
      4. A. Soroka: integration tests in this context may be better for exposing errors
      5. Andrew Woods: we need to improve coverage in a meaningful way. This isn't a policy, but we need a conversation on what are the behaviors of a class and what should the contracts be?
  4. PCDM
    1. pull request for a set of terms of file types. Opportunity for community to use the same terms.

      1. PR for PCDM but we have no committers

      2. What is the scope of the PCDM? Unknown User (escowles@ucsd.edu): supportive of a broader scope for this

    2. Andrew Woods wIll ask community for nomination of initial committers, will send to various email lists

      1. Stefano Cossu noted that replies to messages sent to multiple lists can sometimes remain on one of those lists, without being broadcast back to everyone
  5. Fedora 3.8.1
    1. Release candidate 3 is ready, built against JAVA8, Andrew Woods will send out a message to the community
  6. F4 Import/Export
    1. This will be discussed next week. It may be possible to handle with content negotiation.


 

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.