Time/Place

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

Attendees 

Agenda

  1. Release 4.4.0 is at the doorstep

    1. Final compatibility testing, sample-dataset and camel?
  2. Goals for before 2016, likely one more release
    1. Reference: technical priorities
  3. Individual priorities?
  4. Tech Meeting host for next week?

Ticket Summaries

  1. Please squash a bug!

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  1. The 4.4.0 release is ready. Andrew Woods is adding release documentation. It is anticipated that an additional release will be cut before the new year.
    1. One development goal has been decoupling fcrepo components, meaning that releases can be decoupled. This should make releases easier. For the bundled modules (fcrepo-audit, fcrepo4-oaipmh, etc) they will still be released with the main fcrepo artifacts, at least until OSGi support is more mature.
    2. There is currently no release tooling for backwards compatibility. A sample dataset would be useful for this, where, e.g. a 4.3.0 dataset is available and a 4.4.0 fedora release candidate is installed on top of that.
    3. This could form the start of a test compatibility kit (TCK), which would be focused on the specified fedora API. For example, create a set of resources through the REST API, then verify that the resources were created. This would be in addition to existing integration tests. The existing integration tests would tend to be more implementation-specific than a TCK.
    4. One issue that emerged in the release related to the use of SNAPSHOT versions in the deployment of fcrepo-camel-toolbox in karaf. It seems that pax-exam would help with this. Jared Whiklo is making progress on this.
    5. Esmé Cowles will do some basic testing of 4.4.0 on top of an existing 4.3.0 dataset.
  2. Goals for the remainder of 2015
    1. Shrinking the codebase. Extracting fcrepo-transform from the core codebase is nearly complete (see Unable to locate Jira server for this macro. It may be due to Application Link configuration. ), fcrepo-mint may be another candidate for moving to fcrepo4-exts.
    2. Scalability: establishing metrics, storage options for different usage patterns.  Unknown User (daniel-dgi) is interested in testing a distributed installation (especially: a sharded Modeshape storage layer and handling very large files).  Esmé Cowles is interested in testing the limits of a single-node fedora instance. For this, we need something concrete at which to aim: baseline benchmarks, goals, metrics, etc. Using a reference dataset would be useful.
      1. For this, we need a plan so that the people interested in this aren't duplicating efforts. The fcrepo-test-grinder project may be useful for establishing a shared baseline, though the project hasn't been actively maintained recently.
      2. A special topics meeting could be focused on setting up a common environment that can be used for these benchmark tests. Andrew Woods will send out a poll to meet about this next week.
    3. Backup: serializing data to disk.
    4. Separating API from the implementation and versioning separately.
  3. Esmé Cowles to chair next week's meeting in Andrew Woods' absence.

 

 

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